# **Установка 2** **Курс Ульяны 110626 ТЮМГУ** --- # **Слайд 1\. Малый эксперимент в поле больших университетских моделей** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** сразу задать не инструментальную, а масштабную рамку занятия. Мы не учим пользоваться ИИ; мы показываем, как малый эксперимент преподавателя может быть пробным элементом новой университетской модели. **Заголовок:** **Малый эксперимент в поле больших университетских моделей** **Главная формула:** **Не каждый эксперимент должен быть радикальным. Но каждый эксперимент должен понимать, какую большую возможность он проверяет.** ## **Текст для выступления \+ комментарии для сборки** ### Начать мне хочется не с искусственного интеллекта. Хотя занятие как будто про искусственный интеллект, это как раз ловушка. Как только мы говорим «ИИ в образовании», в голове сразу включается знакомый набор корзин. У кого-то это ChatGPT, у кого-то запреты, у кого-то автоматизация проверки, у кого-то бот, который отвечает на вопросы по курсу, у кого-то очередная университетская инициатива: надо внедрить, описать, отчитаться, желательно не пострадать. И если мы сразу пойдём в эту рамку, мы очень быстро получим разговор не об эксперименте, а о наборе инструментов. Кто чем пользуется, кто что пробовал, где какие промпты, какой сервис лучше, почему студенты всё равно хитрее. Но наша задача сегодня другая. Мы смотрим не на ИИ как на инструмент, а на масштаб эксперимента. Малый эксперимент преподавателя может быть локальной педагогической пробой, а может оказаться пробным элементом большой университетской модели. И вот это различение для нас сегодня главное. Представьте самый простой случай. Преподаватель говорит: я хочу сделать бота по материалам курса. Пока он это сказал, мы ещё почти ничего не поняли. Это может быть справочник, который помогает студенту найти нужное место в материалах. Это может быть тьютор, который не даёт готовый ответ, а ведёт студента через затруднение. Это может быть ИИ-персона курса, которая удерживает позицию автора, эксперта или исторической фигуры. Это может быть критик аргументации. Это может быть сборщик следов, который показывает преподавателю, где студент застрял, какие вопросы задавал, где изменил понимание. Это может быть маленький кусок будущей платформы университета, где такие роли создаются, проверяются, поддерживаются и масштабируются. Снаружи всё это может называться одинаково: «бот». Но внутри это разные проекты. И если мы не различаем эти уровни, мы начинаем заниматься презентационной магией: одно слово закрывает собой слишком много разных вещей. В результате человек говорит «ИИ-персона», а на деле делает справочник. Говорит «исследовательский ассистент», а на деле получает пересказ литературы. Говорит «новая модель оценивания», а на деле просит студентов поставить галочку «использовал ИИ». Формально всё про ИИ, содержательно — очень разные масштабы. Поэтому первый вопрос сегодня такой: ваш эксперимент — это просто локальное улучшение или он проверяет элемент более крупной модели? И здесь не надо всем срочно становиться авторами университета будущего. Это было бы смешно и вредно. Большинство нормальных экспериментов начинается с маленького хода: изменить одно задание, перестроить один фрагмент курса, проверить одну функцию, увидеть один тип следов, сделать один сценарий взаимодействия. Но даже маленький эксперимент должен понимать, какую большую возможность он проверяет. Если вы делаете ИИ-персону курса, вы можете проверять не только удобство общения студента с ботом. Вы можете проверять новую модель распределения функций преподавателя: что остаётся за преподавателем, что уходит в ИИ-персону, где нужен методист, где нужен инженер, где появляется новая педагогическая технология. Если вы делаете тьютора, вы проверяете не просто «помогает ли бот», а можно ли вынести часть учебного сопровождения в диалоговый контур, не разрушив собственное действие студента. Если вы делаете исследовательского ассистента, вы можете проверять элемент research pipeline: как студент формулирует вопрос, выбирает источники, отбрасывает слабые гипотезы, фиксирует ход исследования. Если вы делаете оценочный сценарий, вы можете проверять модель добросовестности в эпоху LLM: как отличить сформированную способность от гладко сгенерированного продукта. Это особенно важно для ТюмГУ, потому что мы не стартуем из пустого места. Уже есть опыт экспериментов, ИИ-персон, центра образовательных разработок, R\&D-семинаров, форума. Это значит, что следующая задача не в том, чтобы ещё раз сказать «ИИ может быть полезен». Это уже неинтересно. Следующая задача — научиться видеть множество экспериментов как поле. Не как сто пятьдесят отдельных историй, каждая на своём языке, каждая со своим маленьким героизмом, каждая потом лежит в отдельной презентации. А как портфель: где видно, какие решения повторяются, какие проекты можно соединить, где нужна лаборатория, где нужен общий конструктор, где появляется радикальная ветка, а где достаточно аккуратного педагогического пилота. И вот здесь возникает главный тезис первого слайда: малый эксперимент проверяет элемент большой модели. Не каждый эксперимент должен быть радикальным. Но каждый эксперимент должен понимать, какую большую возможность он проверяет. Иначе мы через полгода получим обычный университетский отчёт: было много активностей, участники проявили интерес, состоялся продуктивный обмен мнениями. После этой фразы обычно можно выключать проектор и выносить тело инициативы. Нам нужен другой результат. Нам нужно, чтобы каждый проект можно было прочитать: что он меняет, какой тип ИИ использует, какие роли перераспределяет, какие следы оставляет, с какой большой моделью связан, где его можно масштабировать, а где честно остановить как локальный эксперимент. Маленький проект может быть сильным, если он честно описан. Большой проект может быть слабым, если он является просто переименованным ботом. Поэтому сегодня мы начинаем не с вопроса «какой ИИ вы хотите использовать», а с вопроса «в каком большом поле стоит ваш маленький эксперимент». ### **Источники / notes** В заметках держать: * опыт ТюмГУ: 60+ экспериментов, 60+ ИИ-персон, 2000+ студентов, Центр образовательных разработок; * корпус кейсов: campus platforms, builders, sandboxes, course-personas, research pipelines; * проектная гипотеза про агентно-оркестрационный университет как горизонт, а не обязательный результат для всех. --- --- # **Слайд 2\. Базовый контур уже задан: что добавляет вторая установка** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать, что первая установка не игнорируется и не повторяется. Она задаёт базовый экспериментальный контур; вторая установка добавляет координаты масштаба, ИИ-типа и архитектурного паттерна. **Заголовок:** **Базовый контур уже задан: что добавляет вторая установка** **Главная формула:** **Первая установка дала экспериментальный контур. Вторая добавляет координаты ИИ-архитектуры и масштаба.** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь важно зафиксировать, что мы не начинаем всё заново. Первая установка уже дала базовый контур эксперимента. Там была не декоративная часть, а обязательная методическая основа: как выбирать пространство эксперимента, как видеть проблему, как отличать проблему от желания, как формулировать образовательный результат, как переходить к исследовательскому вопросу, гипотезе, операционализации, дизайну, ТЗ, пилоту, отчёту. И это не надо сейчас повторять. Более того, если я начну это повторять, мы потеряем время и собьём конструкцию. Нам важно не заменить первую установку, а положить поверх неё второй слой. Первая установка отвечает на вопрос: как сделать образовательный эксперимент доказательным. Вторая установка отвечает на вопрос: какой ИИ-контур находится внутри этого эксперимента, какого он масштаба, к какому архитектурному паттерну относится и как его потом можно включить в карту проектов. Почему этого второго слоя недостаточно просто «подразумевать»? Потому что в ИИ-экспериментах очень быстро возникает ложная ясность. Человек говорит: я использую ChatGPT. Или: я сделаю ИИ-персону. Или: студенты будут работать с ботом. И всем вроде понятно. Но на самом деле непонятно почти ничего. Возьмём пример. Преподаватель формулирует проблему: студенты не умеют читать сложный теоретический текст. Первая установка спросит правильно: в чём именно затруднение, какой образовательный результат, какая деятельность должна измениться, какая гипотеза, как измеряем, какой дизайн эксперимента. Всё верно. Но для ИИ-эксперимента нужно ещё спросить: кто такой ИИ в этом сценарии? Он справочник? Он тьютор? Он персона автора? Он критик интерпретации? Он навигатор по корпусу? Он фиксирует вопросы студента? Он оставляет следы? Преподаватель видит ход работы? Есть ли риск, что студент просто получит пересказ вместо чтения? Это уже не просто педагогические вопросы. Это вопросы ИИ-архитектуры. Другой пример. Преподаватель хочет использовать ИИ в проектной работе. Первая установка спросит: какая проблема проектного обучения, какой результат, какая гипотеза. Но вторая установка должна спросить: ИИ здесь кто? Симулятор заказчика? Критик требований? Генератор альтернатив? Проверяющий ограничений? Документатор решений? Агент, который ведёт команду через этапы работы? Или просто модель, которая делает красивую презентацию, после которой команда выглядит умнее, чем была? Снаружи всё это называется «использование ИИ». Внутри — разные образовательные механизмы. Поэтому нам нужен второй слой описания. В базовом контуре есть проблема, результат, деятельность, вопрос, гипотеза, операционализация, дизайн, ТЗ, пилот, отчёт. Это держит эксперимент как исследовательскую конструкцию. Но поверх этого нам нужны ИИ-координаты: тип ИИ, стек, уровень изменения, большая модель, архитектурный паттерн, риск снижения планки, сопоставление с кейсами, инфраструктурная цена, место в портфеле. Без первого слоя у нас будет технологическая болтовня. Очень современная, очень уверенная, местами даже с RAG и агентами, но без образовательной ответственности. Без второго слоя у нас будет хороший педагогический эксперимент, но мы не поймём, что именно делает ИИ, почему это не просто новый инструмент, что можно масштабировать и что требует лаборатории. Здесь есть простая формула: первая установка сделала проект педагогически ответственным; вторая должна сделать его архитектурно различимым. Педагогическая ответственность отвечает за то, чтобы мы не внедряли ИИ ради ИИ. Архитектурная различимость отвечает за то, чтобы проект можно было реализовать, сравнить с другими, критиковать на семинарах, довести до ТЗ, включить в портфель. И здесь надо быть довольно жёсткими. Название инструмента не является описанием эксперимента. «Будем использовать ChatGPT» — это примерно как сказать «будем использовать электричество». Прекрасно, но пока неясно, что именно вы включили: лампу, дрель, холодильник или кафедральную мясорубку для отчётности. Точно так же название модели не говорит нам, какую функцию она выполняет в образовательной деятельности. Сегодня мы будем всё время возвращаться к этой связке. Есть базовый экспериментальный контур. И есть второй слой: ИИ-архитектура и масштаб. Не вместо. Поверх. Если эти два слоя соединены, проект становится рабочим. Если они разорваны, либо получается методически корректный, но технологически неразличимый эксперимент, либо технологически красивый, но педагогически пустой. И вот задача второго слайда — зафиксировать это: мы не начинаем сначала, мы добавляем координаты. --- --- # **Слайд 3\. Главная задача: поднять эксперимент на уровень рамки** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** заменить прежний слоповый тезис про «структуру действия». Здесь надо ясно сказать, чем наше занятие отличается от первой установки. **Заголовок:** **Главная задача: поднять эксперимент на уровень рамки** **Главная формула:** **Разница не в названии инструмента, а в масштабе рамки.** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь можно сказать главную задачу сегодняшнего занятия. Она не в том, чтобы дать обзор инструментов. Не в том, чтобы показать внешние кейсы. Не в том, чтобы всех вдохновить на использование ИИ. И уж точно не в том, чтобы помочь каждому придумать «бота». Ботов и без нас придумают. Обычно быстрее, чем потом удаётся понять, зачем они нужны. Главная задача — поднять эксперимент на уровень рамки. Что это значит? Это значит, что мы перестаём принимать название инструмента за описание проекта. Если участник говорит «я хочу сделать бота курса», мы не говорим «отлично, следующий». Мы спрашиваем: в какой рамке существует этот бот? Что он меняет? Какую функцию выполняет? Какие следы оставляет? Какой риск подмены создаёт? С чем он связан в большой модели? Потому что «бот курса» может быть чем угодно. Он может быть справочником по материалам. Студент спросил — бот нашёл. Полезно? Возможно. Меняет ли это образовательную деятельность? Не обязательно. Он может быть тьютором: не отвечать сразу, а вести через затруднение, задавать вопросы, возвращать к критерию. Это уже другой проект. Он может быть ИИ-персоной: удерживать позицию автора, эксперта, исторической фигуры, профессионального оппонента. Это ещё другой проект. Он может быть частью исследовательского пайплайна: помогать формулировать вопрос, работать с источниками, критиковать гипотезу, фиксировать версии. Он может быть элементом кампусной платформы, если такие роли создаются, проверяются, хранятся, масштабируются и поддерживаются университетом. Слово одно. Архитектуры разные. Именно здесь часто происходит первая деградация проекта. Человек берёт сильное слово — «персона», «тьютор», «агент», «симулятор», «платформа» — и надеется, что слово само дотащит смысл. Но не дотащит. Университетская среда вообще богата словами, которые живут дольше дел. «Трансформация», «индивидуализация», «компетенции», «цифровая среда», «образовательная траектория» — некоторые из этих слов уже можно отправлять на пенсию с почётом. Они многое пережили. Но нам нужно не слово, а устройство действия. Поэтому мы вводим три рамки. Первая рамка — локальная доработка. Проект улучшает элемент курса, задания, обратной связи, подготовки материалов. Это может быть вполне нормально. Не надо презирать локальные доработки. Иногда именно они честнее больших заявок. Вторая рамка — перепроектирование деятельности. Здесь меняется способ работы студента, преподавателя, группы, исследовательской или проектной команды. Не просто продукт стал красивее, а действие устроено иначе. Появляются попытки, обратная связь, исправления, следы, рефлексия, новые роли. Третья рамка — прототип большой модели. Здесь локальный эксперимент проверяет элемент будущей университетской инфраструктуры: ИИ-персону, агентный контур, исследовательский пайплайн, проектную студию, модель добросовестности, campus AI platform. Эти рамки не надо понимать как лестницу, где все обязаны взбираться наверх. Первый уровень не плохой, третий не хороший. Плохим становится не маленький масштаб, а нечестное описание масштаба. Если проект меняет только удобство подготовки материалов, не надо называть это трансформацией образовательного процесса. Если проект заявляет ИИ-персону, но фактически даёт студенту справочник, надо признать, что это справочник. Если проект заявляет новую модель добросовестности, но сводится к галочке «я использовал ИИ», это не модель добросовестности, а административный пластырь на переломе. Можно взять простой пример из гуманитарного курса. ИИ-персона Канта. В слабой версии это справочник, который пересказывает Канта человеческим языком. В средней версии это собеседник, который помогает студенту различить рассудок, разум, опыт, априорное, трансцендентальное. В сильной версии это позиционный оппонент, который не даёт студенту скатиться в психологизацию, требует основания, возвращает к структуре аргумента, фиксирует версии понимания. А если таких персон много, они связаны с материалами курсов, проходят проверку, оставляют следы и включаются в общую платформу, это уже другой уровень. Вот почему мы сегодня будем всё время делать один и тот же, слегка неприятный, но полезный ход. Вы называете идею. Мы спрашиваем: в какой рамке она существует? Что реально меняется? Где риск деградации? Какой след докажет, что это не просто гладкий продукт? Что потребуется от преподавателя, студента, методиста, инженера, лаборатории? Это не философская игра. Это способ довести проекты до состояния, когда их можно сопровождать, критиковать, реализовывать и включать в портфель. Иначе в сентябре мы получим набор ИИ-попробовалок. Некоторые будут милые, некоторые полезные, некоторые даже эффектные. Но как университетская программа они не соберутся. Поэтому главный тезис здесь простой: разница не в названии инструмента, а в масштабе рамки. ### **Комментарии для сборки слайда** Слайд должен показывать центральный объект «бот курса / ИИ-ассистент» и разные рамки чтения вокруг него: справочник, тьютор, ИИ-персона, research pipeline, campus platform, governance-контур. Не делать линейную цепочку и не делать пирамиду зрелости. Отдельно показать три рамки: локальная доработка, перепроектирование деятельности, прототип большой модели. Визуальный смысл: один объект может означать разные проекты в разных рамках. Главная формула внизу: «Разница не в названии инструмента, а в масштабе рамки». Оранжевую плашку не делать огромной. --- --- # **Слайд 4\. Две траектории после первой установки** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** убрать слабый блок Edu/Res/Dev и заменить его рабочим развилочным слайдом. **Заголовок:** **Две траектории после первой установки** **Комментарий на слайде:** **Базовая траектория обязательна. Расширенная — для тех, кто хочет поднять эксперимент до сильной университетской модели.** --- ## **Текст для выступления \+ комментарии для сборки** ### После этого важно сразу снять возможное напряжение. Всё, что я сейчас говорю про рамки, большие модели, архитектурные паттерны и портфели, не означает, что каждый участник должен немедленно сделать радикальный проект. Это было бы плохой постановкой. Если в программе сто пятьдесят человек, и мы скажем, что все должны выйти с прототипом новой университетской модели, мы получим не сто пятьдесят сильных проектов, а сто пятьдесят способов имитировать масштаб. Университеты и так умеют имитировать масштаб с большим профессионализмом. Нам не надо усиливать эту компетенцию. Поэтому после первой установки есть две траектории. Первая — базовая. Она обязательна и нормальна. Человек берёт проблему, формулирует гипотезу, проектирует дизайн, готовит пилот, проводит эксперимент, собирает отчёт. Это корректный образовательный эксперимент. Здесь задача — не произвести революцию, а честно проверить изменение в образовательной деятельности. Для большинства проектов это и будет правильный путь. И это не слабая траектория. В реальном университете нормально провести эксперимент — уже большая работа. Нужно успеть в расписании, не разрушить курс, не потерять студентов, не перепутать желание с гипотезой, не подменить образовательный эффект удовлетворённостью, не забыть про ТЗ, не утонуть в технических деталях, не уйти в лозунг. Это вполне серьёзная работа. Вторая траектория — расширенная. Она нужна для проектов, где появляется архитектурная ставка. Не потому что автору хочется выглядеть крупнее. А потому что сам проект начинает выходить за границы одного курса или одного задания. ИИ-персона оказывается не единичным ботом, а элементом экосистемы. Оценивание оказывается не проверкой работ, а вопросом доказательства вклада в эпоху LLM. Исследовательский ассистент оказывается началом research pipeline. Проектный симулятор требует связи с лабораторией и внешними заказчиками. Сборщик следов требует общего формата данных. Несколько похожих проектов показывают, что университету нужен не набор отдельных решений, а общий конструктор. Вот такие проекты стоит вести как архитектурные прототипы. Они могут стать материалом для R\&D, для форума, для отдельного доклада, для инженерной задачи, для портфеля университета. Их не должно быть слишком много. Если из сто пятидесяти человек появится пять-десять-пятнадцать проектов такого масштаба, это уже может быть главным результатом программы. Но их надо не назначать сверху, а обнаруживать по структуре. Здесь важно не создать иерархию: базовая траектория — для обычных, расширенная — для лучших. Нет. Это неправильная и вредная рамка. Сильный преподаватель может делать базовый эксперимент, потому что у него точная проблема и честная гипотеза. А человек в расширенной траектории может произвести туман, если не удержит инфраструктурную цену. Расширенная ветка не лучше. Она дороже, рискованнее и требует другого языка. Можно посмотреть на один и тот же проект в двух траекториях. Допустим, преподаватель делает ИИ-критика эссе. В базовой траектории он проверяет, улучшает ли критик аргументацию, как студенты работают с обратной связью, какие версии текста появляются, какие критерии помогают. В расширенной траектории тот же проект становится элементом модели добросовестности: как доказать вклад студента, какие следы нужны, как отличить продукт от способности, какие задания больше не работают, какие новые формы оценки появляются. Или ИИ-персона курса. В базовой траектории это один курс, одна персона, один сценарий, один пилот. В расширенной — вопрос экосистемы персон: как их создавать, проверять, хранить, переносить, как задавать позицию, как обучать преподавателей быть авторами таких ролей, какая инфраструктура нужна. Поэтому на этом слайде я хочу зафиксировать развилку. У всех есть базовая траектория: проблема, гипотеза, дизайн, пилот, отчёт. У части проектов может появиться расширенная: тип ИИ, масштаб изменения, архитектурный паттерн, большая модель, ТЗ, R\&D, портфель. Нам нужны обе. Без базовой траектории всё улетит в красивые разговоры. Без расширенной — мы получим аккуратные локальные эксперименты, но не увидим границу новой университетской модели. --- --- # **Слайд 5\. ИИ не один: концепты, архитектуры, формы встраивания** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** открыть не «историю ИИ», а поле разных онтологий ИИ. **Главная формула:** **Разные концепции ИИ дают разные формы университетского действия.** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь мы переходим к полю ИИ. И здесь снова есть риск. Очень хочется сделать краткую историю искусственного интеллекта: кибернетика, экспертные системы, машинное обучение, нейросети, трансформеры, агенты. Но нам не нужна музейная экскурсия. Мы не собираемся водить аудиторию вдоль витрин: вот здесь у нас экспертная система, не кормить; вот здесь нейросеть, осторожно, может галлюцинировать; вот здесь агент, он ещё маленький, но уже строит workflow. Нам нужна не история, а различительная карта. Потому что когда преподаватель говорит «ИИ в моём эксперименте», он может иметь в виду совершенно разные типы машинности. И если этот тип не различить, проект будет собран криво. Сегодня ИИ чаще всего автоматически сжимается до LLM или чат-бота. Это понятно. LLM видимы, разговорчивы, удобны, иногда пугающе убедительны, иногда уверенно несут чушь, но в любом случае они уже стали новым участником образовательной коммуникации. Но ИИ не сводится к LLM. Есть линия аналитики и машинного обучения. Она не обязательно разговаривает. Она помогает видеть состояние системы, строить прогноз, распознавать риск, фиксировать ошибки, адаптировать траекторию. В университете это learning analytics, карты затруднений, индивидуальные траектории, риск-диагностика, мониторинг участия. Есть символический ИИ. Это правила, фреймы, онтологии, экспертные системы, деревья решений, сценарии рассуждения. Он важен там, где нужно явно описать структуру экспертного действия. Например, как юрист видит ситуацию? Как врач ставит диагностический вопрос? Как инженер распознаёт тип противоречия? Как историк проверяет источник? Как методолог различает проблему и тему? Здесь недостаточно просто дать LLM роль «будь экспертом». Надо описать структуру экспертного действия. Есть domain и foundation models — модели, работающие с предметными пространствами: изображениями, молекулами, белками, материалами, медицинскими данными, инженерными объектами. Для образования это важно, потому что университет — это не только учебная аудитория. Это ещё исследование, разработка, лаборатория, проектирование. Если студент входит в научную или инженерную деятельность, ИИ может быть не собеседником, а участником работы с предметным объектом. Есть LLM. Это отдельный и мощный слой. LLM работают через язык, текст, код, объяснение, аргументацию, инструкцию, отчёт, критику, диалог. Поэтому они так легко входят в университет: университет исторически держится на текстах, объяснениях, вопросах, доказательствах, интерпретациях, письме, чтении, коде и отчётах. LLM меняют не один инструмент, а среду работы с языковыми и знаковыми формами. Есть agents, workflow, RAG, процессные сборки. Здесь ИИ уже не просто отвечает в чате, а включается в цепочку: взять материалы, найти фрагменты, вызвать модель в нужной роли, проверить, зафиксировать след, передать дальше, собрать отчёт, вернуть преподавателю. Это важно для исследовательских пайплайнов, проектных студий, сборщиков следов, кампусных сервисов. Вот почему вопрос «какой сервис использовать?» вторичен. Название сервиса — не архитектура. ChatGPT, Claude, GigaChat, Perplexity — это в лучшем случае поставщик моторчика. А нам надо понять, что этот моторчик крутит: вентилятор, дрель, кофемолку или административную мясорубку. Иначе мы проектируем не эксперимент, а способ подключить модную штуку к старому процессу. Тип ИИ должен вытекать из гипотезы. Если проблема в том, что студент не видит свои повторяющиеся ошибки, возможно, нужен аналитический слой и следы. Если проблема в том, что студент не умеет применять экспертные критерии, нужен символический слой: правила, рубрики, фреймы, сценарии. Если проблема в чтении, письме, аргументации, объяснении, коде — нужен LLM. Если проблема в организации цепочки действий — нужны workflow, RAG, агенты. Если проблема в исследовательской работе с предметным объектом — нужны domain models или AI-for-Science. И ещё важнее: сильный эксперимент часто собирает несколько слоёв. Например, ИИ-персона курса — это не просто LLM. В сильной версии это LLM плюс материалы курса, возможно RAG, плюс сценарий диалога, плюс границы роли, плюс следы взаимодействия, плюс преподавательская интерпретация. Исследовательский ассистент — это не просто чат для обзора литературы. Это корпус источников, структура вопроса, критик гипотезы, лог отказов, проверка метода, следы работы. Проектная студия — это не просто генерация идей. Это сценарий требований, симулятор заказчика, проверка ограничений, фиксация альтернатив. Поэтому на этом этапе нам нужна карта типов ИИ, а не список сервисов. Мы должны научиться говорить: в моём эксперименте ИИ работает как аналитический слой, как символическая структура экспертного действия, как LLM-собеседник, как RAG по материалам, как workflow, как исследовательский агент, как элемент платформы. Только тогда проект можно будет нормально обсуждать. Главный тезис здесь: разные концепции ИИ дают разные формы университетского действия. И если мы хотим проектировать эксперимент, а не просто внедрять инструмент, мы должны различать эти формы. --- --- # **Слайд 6\. Кибернетика, аналитика, ML: ИИ как регуляция и предсказание** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** первый тип ИИ — не LLM, а управление через данные и обратную связь. ## **Текст для выступления \+ комментарии для сборки** ### Первый тип ИИ, с которого я хочу начать, — не LLM. Это специально. Все ждут разговора про LLM, потому что именно они сейчас на поверхности: они пишут, спорят, объясняют, иногда льстят, иногда уверенно ошибаются, иногда делают вид, что поняли, и этим, кстати, напоминают не только студентов. Но если мы сразу начнём с LLM, мы закрепим ошибку: будто ИИ в образовании — это прежде всего чат. А в образовательном эксперименте часто важнее не разговор, а видимость состояния системы. Кибернетическая линия ИИ — это обратная связь, данные, модель состояния, интервенция, новая обратная связь. Машина здесь не обязана разговаривать человеческим голосом. Она должна помогать видеть, что происходит. Где студент застрял. Где группа потеряла темп. Где задание оказалось слишком лёгким или слишком мутным. Где мотивация начала падать. Где повторяются ошибки. Где студент получил хороший продукт, но не сформировал действие. Где обратная связь приходит слишком поздно. Где все кивают, а понимания нет. Это очень простая, но неприятная вещь: образовательный процесс в значительной части невидим. Мы видим итоговый текст, итоговую презентацию, ответ на семинаре, иногда выражение лица. Но выражение лица — ненадёжный прибор. Студент может смотреть глубоко, а внутри выбирать доставку. Преподаватель может чувствовать, что всё идёт хорошо, а потом увидеть работы и понять, что шло куда-то не туда. Группа может казаться активной, но активность может быть имитацией. Итоговый продукт может выглядеть прилично, особенно теперь, когда LLM умеют делать гладкие поверхности. Вот здесь аналитика и ML важны не как контроль, а как слой видимости. Не полицейский участок при курсе. Не дашборд ради дашборда. Не цифровая панель, где всё считается, но никто не понимает, что это значит. А контур, который помогает увидеть следы образовательного действия. Что может становиться видимым? Участие, ошибки, затруднения, версии, попытки, возвраты, динамика мотивации, индивидуальные траектории, типовые сбои, моменты делегирования ИИ, изменение формулировок. В некоторых случаях это можно считать количественно. В некоторых — фиксировать как качественные следы. Важно не свести всё к цифрам. Не всё важное измеряется, и не всё измеренное важно. Но если следов нет вообще, мы часто не можем отличить сформированную способность от красиво сгенерированного результата. Возьмём ИИ-персону курса. В слабой версии студент просто поговорил с персоной, получил ответы и ушёл. Что произошло? Неизвестно. Может, он понял. Может, получил пересказ. Может, научился обходить чтение. Может, просто почувствовал, что курс стал удобнее. В сильной версии мы видим следы: какие вопросы он задавал, где возвращался, какие версии понимания менял, где начал спорить, где принял подсказку без основания, где исправил свою формулировку. Тогда преподаватель видит не только факт использования ИИ, а траекторию работы. Другой пример — проектный симулятор. В слабой версии команда сгенерировала идеи и сделала гладкую презентацию. В сильной версии фиксируются альтернативы, отказы, основания выбора, столкновение с ограничениями, реакция на критику, изменение спецификации. Тогда аналитика не просто считает клики, а показывает структуру проектного действия. Третий пример — исследовательский ассистент. В слабой версии он пересказывает литературу. В сильной версии остаются версии исследовательского вопроса, основания выбора источников, отклонённые гипотезы, слабые места операционализации, следы проверки метода. Это уже похоже на материал научного мышления, а не просто на генерацию текста. Поэтому вопрос этого слайда такой: какие состояния и следы должны стать видимыми, чтобы мы могли говорить об эффекте? Если эксперимент заявляет, что студент стал лучше аргументировать, надо увидеть не только итоговое эссе, но и ход изменения аргумента. Если эксперимент заявляет, что студент лучше понимает теорию, надо увидеть не только пересказ, но и работу с затруднениями. Если эксперимент заявляет, что команда лучше проектирует, надо увидеть не только финальную презентацию, но и альтернативы, ограничения, отказы, основания выбора. Это напрямую связано с доказательностью внедрения. Доказательность — это не только методика измерения на входе и выходе. В ИИ-среде доказательность всё больше становится вопросом следов. Кто что сделал? Что было делегировано машине? Что было проверено человеком? Где возникла ошибка? Где произошло исправление? Где изменилась позиция? Где продукт стал лучше, но действие не изменилось? И это же связано с добросовестностью. Добросовестность в ИИ-среде — не только «студент честно сказал, пользовался ли он ChatGPT». Это слишком слабая рамка. Добросовестность — это возможность восстановить вклад, процесс, версии, проверки, ошибки, делегирование и человеческое присвоение результата. Аналитический слой помогает не ловить студентов за руку, как в плохом детективе, а проектировать такие задания, где видна работа. Поэтому первый тип ИИ, который мы обсуждаем, — ИИ как регуляция и предсказание. Он делает образовательную систему наблюдаемой. И иногда это важнее, чем ещё один умный собеседник. Потому что если мы не видим действия, LLM легко превращается в генератор красивых поверхностей. А красивые поверхности образование и до ИИ производило прекрасно: цель, задачи, ожидаемые результаты, титульный лист, всё как положено, только внутри пустовато. Наша задача не увеличить производство таких поверхностей. Наша задача — увидеть, где действительно меняется действие. ### **Как связать с будущими заданиями** В задании 1 участник должен будет спросить: «а мой проект вообще использует аналитику? Нужны ли данные, мониторинг, логирование, предиктивная модель, следы?» Это может усилить даже простой LLM-проект. ### **Пример для пояснения** Если у преподавателя есть эксперимент с ИИ-персоной, можно усилить его аналитическим слоем: не просто студент поговорил с персоной, а система видит, какие вопросы он задавал, где застрял, как менялись версии, сколько раз возвращался к критерию. ### **Что не должно быть** Не уходить в техническое объяснение регрессии или ML. Этот слайд не о методах машинного обучения, а об университетской функции: **видеть состояние и менять режим действия**. --- # **Слайд 7\. Символический ИИ: правила, фреймы, экспертные действия** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать другую линию: не данные и предсказание, а формализованное экспертное рассуждение. **Заголовок:** **Символический ИИ: правила, фреймы, экспертные действия** ## **Текст для выступления \+ комментарии для сборки** ### **Текст для произнесения** После аналитики и машинного обучения нужно показать вторую линию ИИ, о которой сейчас часто забывают, потому что все зачарованы большими языковыми моделями. Это символический ИИ: правила, фреймы, сценарии, онтологии, деревья решений, экспертные системы, модели рассуждения. Он может казаться старым, почти музейным. Но для образования он не просто не устарел — он становится особенно важным, потому что именно здесь возникает вопрос: можем ли мы явно описать экспертное действие? В образовании мы постоянно имеем дело не только с информацией, но и с нормами действия. Юрист не просто знает законы. Он видит ситуацию через правовые признаки, различает существенное и несущественное, строит квалификацию, проверяет состав, замечает процессуальные риски. Врач не просто знает симптомы. Он собирает анамнез, строит гипотезы, исключает опасные варианты, понимает, когда данные противоречат друг другу. Инженер не просто знает формулы. Он проверяет ограничения, видит конфликт требований, различает режимы работы системы. Методолог не просто красиво разговаривает о проблемах. Он отличает тему от проблемы, противоречие от трудности, позицию от мнения, схему от украшения. Вот эти действия нельзя хорошо тренировать, если они остаются в виде неявного «ну эксперт же видит». Эксперт видит, а студент не видит. И если мы хотим, чтобы студент научился видеть, надо хотя бы частично вынести структуру экспертного действия наружу. Не всю, не идеально, не как мёртвую инструкцию, но достаточно, чтобы её можно было передавать, проверять, обсуждать, критиковать. Символический ИИ важен именно здесь. Он задаёт язык явных различений: если есть такой признак, проверь такой риск; если ситуация относится к такому типу, используй такую рамку; если аргумент устроен так, ищи такое слабое место; если исследовательский вопрос сформулирован так, проверь его операционализацию; если студент путает причину и корреляцию, верни его к структуре объяснения. Это не означает, что мы возвращаемся к старым экспертным системам и забываем LLM. Наоборот. Сильная ИИ-персона, тьютор или критик почти всегда нуждается в символическом слое. Если мы просто говорим модели «будь юристом», «будь врачом», «будь Кантом», «будь методологом», мы получаем стилизацию. Иногда приятную, иногда убедительную, иногда опасную. Но стилизация не равна экспертному действию. Экспертность начинается там, где задана структура различений: на что смотреть, какие признаки считать существенными, какие ошибки отслеживать, какие вопросы задавать, где останавливать студента, что не давать ему перепрыгнуть. Например, ИИ-критик исследовательского дизайна. В слабой версии он говорит: «ваш вопрос нужно уточнить, гипотеза должна быть проверяемой, метод должен соответствовать цели». Это универсальная вата, слегка пахнущая методологией. В сильной версии он проверяет: есть ли различение объекта и предмета, есть ли операционализация, не подменяется ли гипотеза ожиданием, различены ли переменные, есть ли дизайн наблюдения, понятно ли, по каким данным можно будет сделать вывод. Это уже не просто LLM, это LLM, усиленная символической структурой экспертного разбора. Или ИИ-персона философа. Если это просто персона, которая говорит красивым языком, мы получим театральный справочник. Но если у неё есть фреймы различения — например, для Канта: рассудок/разум, эмпирическое/трансцендентальное, априорное/апостериорное, явление/вещь-в-себе, условие возможности/психологический механизм — тогда персона может не только отвечать, но и ловить типовые ошибки понимания. Она может сказать студенту: ты сейчас психологизируешь трансцендентальное; ты заменил вопрос об условиях возможности вопросом о происхождении представлений; ты используешь слово «опыт» в до-критическом смысле. Вот это уже педагогически интересно. В инженерном или проектном курсе символический слой может задавать проверку ограничений. Не просто «сгенерируй решение», а проверь: какие требования конфликтуют, где физическое противоречие, где ресурс, где ограничение безопасности, где стоимость, где технологичность, где обслуживание. В юридическом курсе — дерево квалификации кейса. В клиническом — сценарий дифференциального рассуждения. В исследовательском семинаре — карта проверки вопроса и гипотезы. В методологическом разборе — различение проблемы, позиции, рамки, основания. Поэтому университетский вопрос этого слайда такой: какие экспертные действия можно явно описать, передать и проверить? Не какие знания можно загрузить в базу. Не какой текст можно дать модели. А именно какие действия эксперта можно вынести в форму правил, фреймов, сценариев, рубрик, деревьев решений, онтологий. Это особенно важно для образовательного эксперимента. Если эксперимент заявляет, что студент учится мыслить как инженер, юрист, врач, исследователь, методолог, аналитик, то нужно понять: какая структура этого мышления становится видимой? Где ИИ помогает не заменить эксперта, а вынести его различения в учебную ситуацию? Если этого нет, то мы снова получаем помощника, который говорит умные слова, но не формирует действие. Символический ИИ — это не прошлое. Это слой явной экспертной структуры, без которого LLM легко превращается в гладкого говоруна. А гладкий говорун в университете — существо хорошо знакомое, местами даже институционализированное. Нам нужно не умножать гладкость, а сделать экспертное действие различимым. ## **Подробная сборка слайда** ### **Функция слайда** Показать вторую важную линию ИИ после кибернетики/аналитики: ИИ как формализация экспертного действия, правила, фреймы, сценарии, онтологии и процедуры рассуждения. Этот слайд нужен, чтобы преподаватели не воспринимали ИИ только как «нейросеть, которая генерирует текст». До нейросетевой генерации был мощный пласт ИИ, связанный с явным описанием знания и экспертных процедур. Для нашего занятия это особенно важно: многие образовательные эксперименты требуют не просто генерации ответа, а выявления структуры экспертного действия. Например, как юрист разбирает кейс, как инженер проверяет ограничение, как исследователь строит гипотезу, как врач проводит дифференциальную диагностику, как историк работает с источником, как философ различает позиции. ### **Пример для пояснения** Простой пример: «Если преподаватель хочет сделать ИИ-персону юриста, врача, историка или методолога, мало сказать модели “будь экспертом”. Нужно понять, какие признаки эксперт различает, какие вопросы задаёт, какие ошибки не допускает, какие основания требует. Это уже не просто LLM, а соединение языковой модели с символической структурой экспертного действия». ### **Связь со следующим слайдом** После слайда 7 переходим к нейросетям и foundation/domain models: там объект уже не только правила и фреймы, а большие предметные пространства — белки, молекулы, изображения, материалы, климат, данные. --- --- # **Слайд 8\. Нейросети и foundation/domain models: работа с предметными пространствами** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать, что до LLM уже возникали машины, меняющие науку и разработку. --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь нужно сделать ещё один сдвиг. До LLM уже возникали машины, которые меняли науку, разработку и инженерную практику. Они не обязательно разговаривали с нами человеческим языком, не обязательно писали эссе, не обязательно вели диалог со студентом. Но они входили в предметные пространства: изображения, белки, молекулы, материалы, климат, медицинские данные, научные симуляции. Это важно, потому что университет — не только место, где люди читают тексты и пишут отчёты. Университет — это ещё лаборатория, исследовательская группа, инженерная разработка, работа с объектами, данными, моделями, измерениями. Когда мы говорим о foundation models или domain models, мы говорим о другом типе ИИ. Это не просто ассистент, который помогает сформулировать мысль. Это машина, которая работает с предметной областью как с пространством закономерностей. AlphaFold не стал важным потому, что красиво объяснил белки. Он стал важным потому, что изменил способ работы с белковыми структурами. Модели молекул важны не потому, что они могут написать реферат про химию, а потому что позволяют иначе искать кандидаты, оценивать свойства, сокращать пространство проб. Модели материалов, климата, медицинских изображений, инженерных симуляций работают не как говорящие помощники, а как участники исследования и разработки. Для образования это имеет прямое значение. Если студент входит в исследовательскую или инженерную деятельность, он должен учиться не только пользоваться чат-ботом, но и понимать, как ИИ меняет саму структуру работы с объектом. Что теперь значит «эксперимент»? Что значит «модель»? Что значит «гипотеза», если часть пространства вариантов уже предварительно обходит машина? Что значит подготовка исследователя, если он должен уметь работать не только с литературой, но и с моделями, данными, симуляциями, вычислительными помощниками, которые видят не так, как человек? Здесь появляется очень важный образовательный вопрос. Раньше студент учился входить в предметную область через учебник, лабораторную работу, расчёт, семинар, практику. Теперь во многих областях между студентом и предметом появляется модель. Не просто инструмент, а машинный посредник, который умеет распознавать, предсказывать, генерировать, искать варианты. И студент должен понимать, что делает эта модель, где её границы, что она видит, чего не видит, как её проверять, как не спутать машинную уверенность с научным знанием. Это касается не только естественных наук. В инженерии модели могут помогать с конструкциями, материалами, режимами работы, цифровыми двойниками. В медицине — с изображениями, диагностическими паттернами, данными пациентов. В климате — со сценариями и моделями. В экономике — с прогнозами и сложными системами. В гуманитарных областях тоже появляются свои предметные модели: корпусные анализы, семантические карты, реконструкция дискурсов. Но в этом слайде важно удержать именно предметность: ИИ работает не только с текстом о мире, но и с моделируемыми структурами самого мира. И здесь сильная образовательная ставка. Если мы готовим исследователя или инженера, мы должны готовить его к работе в среде, где предметная область частично доступна через ИИ-модели. Это не значит, что человек исчезает. Наоборот, человеческая интерпретация, постановка вопроса, проверка, критика, ответственность становятся ещё важнее. Но они меняют место. Исследователь уже не просто сам перебирает варианты. Он организует взаимодействие с машинным пространством вариантов. Он должен понимать, где модель ускоряет исследование, где создаёт иллюзию результата, где требует верификации, где открывает новую гипотезу, а где просто красиво ошибается. Для университета это означает: ИИ в образовании нельзя сводить к курсам и заданиям. Есть зона исследования, лаборатории, инженерной разработки. И если образовательный эксперимент связан с научно-исследовательским семинаром, проектным обучением, лабораторной работой, инженерным проектированием, магистерской или аспирантской подготовкой, там может появиться не только LLM-помощник, но и domain model, симуляция, модель данных, AI-for-Science pipeline. Можно сказать жёстко: если мы обсуждаем только чат-ботов, мы сильно сужаем университет. Потому что университет не только разговаривает. Он ещё измеряет, проектирует, моделирует, экспериментирует, строит, проверяет, лечит, рассчитывает, наблюдает. LLM вошли в язык университета, но domain models входят в предметные практики университета. И это разные линии трансформации. Вопрос к участникам здесь такой: ваш эксперимент касается только учебной коммуникации или он входит в исследование, лабораторию, проектирование, работу с предметным объектом? Если второе, то нужно спросить: какие модели уже меняют эту область? Какие операции раньше делал исследователь или инженер, а теперь может выполнять машинный контур? Что должен понимать студент, чтобы не стать оператором чёрного ящика? Где нужна новая грамотность: не «написать промпт», а работать с моделью предметного пространства? Именно это нужно показать на слайде: ИИ работает не только с языком. Он работает с предметными пространствами. А значит, университетская трансформация затрагивает не только преподавание, но и исследование, лабораторию, инженерную разработку и подготовку исследователя. ### **Пример для пояснения** «Если студент-химик или биолог учится не только читать учебник, но и ставить исследовательский вопрос, работать с моделями, проверять гипотезы, интерпретировать данные, то AI-for-Science становится частью образования. Это не отдельная тема “для лабораторий”, а материал для образовательного эксперимента». ### **Связь с нашей логикой** Этот слайд поддерживает более широкий тезис: университетское образование включает Edu, Res, Dev. Но мы не выносим это как слабый отдельный слайд в начале; мы показываем это через сами формы ИИ. ### **Чего избегать** Не делать вид, что все преподаватели должны немедленно работать с AlphaFold или научными foundation-моделями. Важно показать тип: **ИИ может менять предметное исследование и разработку, а не только коммуникацию с текстом**. --- --- # **Слайд 9\. LLM: язык как интерфейс интеллектуальных операций** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать скачок LLM: они входят в язык — материал университета. **Заголовок:** **LLM: язык как интерфейс интеллектуальных операций** **Главный тезис:** **LLM входит не в один предмет, а в материал университетской работы: чтение, письмо, объяснение, исследование, проектирование, доказательство.** --- ## **Текст для выступления \+ комментарии для сборки** Теперь мы можем перейти к LLM. И важно объяснить, почему именно они произвели такой сильный эффект в университете. Не потому, что это просто ещё один мощный инструмент. Не потому, что они «умные» в каком-то бытовом смысле. А потому, что они вошли в материал университетской работы. Университет держится на языке. Не только гуманитарный университет. Любой университет. Мы читаем тексты, пишем тексты, задаём вопросы, объясняем, спорим, строим аргументы, формулируем гипотезы, пишем код, составляем отчёты, даём инструкции, оцениваем работы, защищаем проекты, оформляем исследования, рецензируем, интерпретируем, переводим между языками разных дисциплин. Даже когда речь идёт об инженерии или медицине, значительная часть работы всё равно проходит через текст, схему, код, отчёт, протокол, критерий, объяснение. LLM вошли именно сюда. Они не просто добавили новый сервис. Они вошли в язык как интерфейс интеллектуальных операций. Поэтому их влияние такое широкое. Они могут работать с текстом, кодом, объяснением, аргументацией, инструкцией, диалогом, отчётом, критерием, исследовательским обзором, проектной документацией. Они оказываются не в одном предмете, а почти в любом месте, где университетская деятельность проходит через знаковые формы. Это принципиально отличает LLM от многих предыдущих инструментов. Калькулятор менял расчёт. Поисковик менял доступ к информации. LMS меняла организацию курса. LLM входят сразу в чтение, письмо, объяснение, проектирование, исследование, программирование, оценивание. Поэтому студенты так быстро начали использовать их не там, где им разрешили, а там, где возникала интеллектуальная нагрузка. Нужно написать эссе — LLM. Нужно понять текст — LLM. Нужно сделать код — LLM. Нужно подготовить доклад — LLM. Нужно объяснить себе задание — LLM. Нужно сделать вид, что ты понял, — тоже LLM, и тут начинается особая педагогическая печаль. Но именно поэтому запретительная рамка слабая. Если студент может делегировать машине интеллектуальную операцию, которую курс считает образовательной, то проблема не только в студенте. Проблема в устройстве образовательного процесса. Мы должны заново спросить: какие операции студент должен делать сам? Какие можно делегировать? Какие можно делать вместе с ИИ? Где делегирование разрушает обучение? Где, наоборот, открывает более высокий уровень работы? Где продукт больше не доказывает способность? Где надо смотреть на процесс, версии, следы, основания? LLM делают явной старую проблему образования: текст сам по себе давно не гарантировал понимания, но теперь это стало видно особенно резко. Студент может сдать красивый текст, не пройдя действие. Может получить объяснение, но не присвоить различение. Может сгенерировать код, не понимая ошибки. Может сделать обзор литературы, не имея исследовательского вопроса. Может получить аргумент, не умея его защищать. Это не значит, что LLM плохи. Это значит, что старые формы проверки стали слабее. Но есть и другая сторона. LLM позволяют строить новые образовательные формы. Они могут быть тьютором, который удерживает студента в зоне ближайшего действия. Критиком, который не переписывает работу, а показывает слабое место. ИИ-персоной, которая вводит в позицию автора или профессионала. Исследовательским собеседником, который помогает уточнить вопрос. Симулятором заказчика. Оппонентом на защите проекта. Навигатором по материалам курса. Помощником в коде, который не просто выдаёт решение, а объясняет ошибку. Но всё это требует сценария, границ, критериев, следов. Иначе LLM превращается в универсальную машину гладкости. Главный тезис слайда: LLM входит не в один предмет, а в материал университетской работы: чтение, письмо, объяснение, исследование, проектирование, доказательство. Поэтому проектировать эксперимент с LLM — это не значит «добавить чат». Это значит понять, какую интеллектуальную операцию мы перестраиваем. Если эксперимент про чтение, нужно спросить: LLM помогает читать или заменяет чтение пересказом? Если про письмо: помогает строить аргумент или производит текст вместо студента? Если про код: помогает понять ошибку или скрывает непонимание за рабочим фрагментом? Если про исследование: помогает поставить вопрос или генерирует обзор без исследовательской позиции? Если про проектирование: расширяет пространство альтернатив или делает презентацию с видом решения? Вот почему LLM опасны и сильны одновременно. Они могут снижать образовательную нагрузку до имитации. И они же могут поднимать студента на более сложный уровень работы, если правильно встроены. Всё зависит не от модели самой по себе, а от архитектуры ситуации. И ещё одна мысль: LLM работают не только как инструмент ответа. Они могут быть участником диалога, носителем роли, критиком, симулятором, посредником между материалами и студентом. Поэтому дальше нам нужно будет отдельно сказать: LLM нельзя понимать только как кодовый модуль. Они действуют в текстовой, смысловой, ролевой среде. Но сначала важно зафиксировать базу: LLM вошли в язык, а язык — это нервная система университета. ### **Переход к следующему слайду** Если LLM работает с языком как интерфейсом действия, то промптинг — это не просто набор хитрых вопросов, а способ конфигурировать ситуацию. Отсюда слайд 10\. --- # **Слайд 9A. О** ## **Текст для выступления \+ комментарии для сборки** ### **Текст для произнесения** Теперь надо остановиться на самой первой ошибке, которую почти все совершают при встрече с LLM. Она кажется маленькой, но дальше из неё вырастает почти всё неправильное использование модели. Студент, преподаватель, инженер, управленец видит LLM и почти автоматически помещает её в знакомую рамку: это машина, которая должна давать ответы. Хорошая машина даёт правильные ответы. Плохая машина ошибается, врёт, галлюцинирует, выдумывает источники, путается и вообще ведёт себя как студент на защите, который прочитал только введение, но держится бодро. В этой рамке LLM сразу начинает выглядеть подозрительно. Она не всегда точна. Она может сгенерировать несуществующую статью. Она может уверенно ошибиться. Она может дать разные ответы на похожие вопросы. Она не гарантирует фактологическую надёжность так, как хочется от справочника или поисковика. И тогда возникает простой вывод: полезно для черновиков, полезно для стиля, полезно для быстрых сводок, но для серьёзной работы ненадёжно. И вот здесь начинается настоящая проблема. Потому что такой вывод одновременно частично верен и глубоко сбивает с толку. Да, LLM плоха как машина окончательных проверенных ответов. Да, её нельзя использовать как справочник без проверки. Да, она не заменяет фактологическую верификацию. Но если из этого делается вывод, что LLM — это просто плохой справочник, мы теряем главный класс её возможностей. Пока студент смотрит на LLM как на машину ответов, он использует её в самых бедных режимах. Найди статьи. Сделай введение. Перепиши текст. Сократи. Суммируй. Подправь стиль. Объясни простыми словами. Всё это может быть полезно, но это низкий режим. В нём модель обслуживает уже заданный запрос. Она не перестраивает задачу, не открывает альтернативы, не испытывает слабые места, не моделирует защиту, не переводит работу между позициями, не помогает увидеть проблему иначе. Сильный режим начинается там, где студент перестаёт спрашивать у модели готовый ответ и начинает использовать её как среду проблематизации и испытания ходов. Не «напиши мне введение», а «покажи, какая скрытая проблема делает мою тему слабой». Не «найди статьи», а «разведи три альтернативные постановки задачи и покажи, какая лучше выдерживает защиту». Не «сделай вывод», а «смоделируй возражения комиссии и покажи, где мой переход проваливается». Не «перепиши красиво», а «найди места, где текст имитирует аргументацию вместо того, чтобы её строить». Формально инструмент один и тот же. Фактически это два разных мира. В первом мире LLM — машина ответов, которой не до конца можно доверять. Во втором — среда порождения, испытания и отбора новых смысловых ходов. И если студент не совершает этот поворот, он так и остаётся в бедном режиме. Он может стать быстрее, аккуратнее, чуть грамотнее, но не станет сильнее в мышлении. Поэтому первая задача курса или установки — не объяснить, как устроены трансформеры. Не начать с temperature, токенов, attention, embeddings и прочей технической кухни. Это всё можно объяснять позже, когда есть правильная оптика. Первая задача — изменить практическую оптику: что студент считает LLM и для чего он её использует. Если он думает: «это машина, которая должна сказать мне правильное», он будет всё время либо разочаровываться, либо списывать. Если он думает: «это среда, в которой можно порождать и испытывать варианты хода мысли», он начинает работать иначе. Он становится не получателем ответа, а оператором поля возможностей. И вот это надо сделать невозможным на старте: наивный взгляд на LLM как на машину правильных и неправильных ответов. Не запретить его морально, а показать его бедность. Он годится для проверки одного класса задач, но убивает главный потенциал LLM. Модель не становится сильной, когда мы начинаем ей верить. Она становится сильной, когда мы учимся заставлять её порождать, сталкивать и проверять ходы, которые у нас самих ещё не возникли. --- # **Слайд 9B. С** ## **Текст для выступления \+ комментарии для сборки** ### Чтобы понять, почему эта ошибка так устойчива, нужно на минуту отойти от LLM и посмотреть на старую модель машинности. Студент не приходит к LLM с пустой головой. Он уже знает, что такое машина. И именно это знание мешает ему увидеть новый объект. Он вырос среди устройств, программ, алгоритмов, приложений, калькуляторов, поисковиков, автоматов, интерфейсов, систем контроля. В этой среде машина почти всегда понимается через функцию. Машина считает, сортирует, ищет, управляет, проверяет, исполняет. Хорошая машина делает то, для чего сделана, и делает это надёжно. Если она дала неправильный результат, значит, она сломалась, плохо запрограммирована или используется неправильно. Эта интуиция абсолютно оправдана в своём домене. Более того, без неё невозможна инженерная цивилизация. Мы хотим, чтобы программа исполнялась предсказуемо. Чтобы код работал одинаково при одинаковых условиях. Чтобы вычисление повторялось. Чтобы автомат не рассуждал творчески, когда ему нужно открыть клапан, рассчитать нагрузку или провести транзакцию. Если банковский софт вдруг начнёт «интерпретировать» платёж в зависимости от жанра, контекста и настроения, у нас будет не философия языка, а уголовное дело. Под этой машинностью лежит сцепка нескольких вещей: логика, вычисление, компьютер, код, исполнение. Логика задаёт формальные правила допустимых переходов: что считается выражением, что принимается как исходное, что из чего следует. Вычисление разворачивает такие переходы по процедуре. Компьютер в стандартном инженерном понимании — машина исполнения формализованных процедур и управления переходами между состояниями. Код — крайний случай текста, в котором пространство интерпретации почти полностью устранено ради однозначного исполнения. Именно эта связка создаёт привычку: надёжное значит предсказуемое, прозрачное, воспроизводимое, однозначно исполнимое. Это не глупая привычка. Она выстрадана всей историей техники, математики, инженерии, программирования и управления. Поэтому студент не ошибается «по тупости», когда ждёт от LLM одного правильного ответа. Он применяет к ней стандарт, который тысячу раз работал в мире кода, расчёта и формальных процедур. Проблема начинается там, где этот стандарт становится единственной нормой машинности. Тогда всё новое читается как ухудшенная версия старого. LLM начинает выглядеть как плохой калькулятор по текстам, плохой поисковик, плохой справочник, плохая программа. Она не всегда повторяет результат. Она не гарантирует факт. Она слишком вариативна. Она не даёт прозрачной цепочки вывода. Она может быть убедительной без истинности. С точки зрения старой машинности всё это дефекты. Но так мы ничего не поймём. Потому что LLM действительно включает вычисление, код, вероятностные операции, инфраструктуру, серверы, алгоритмы. Но её пользовательский и образовательный смысл не сводится к старой машине исполнения. Она работает с языком, а язык устроен иначе, чем код. И если мы не вскроем старую рамку, студент будет считать её не одной исторической моделью машинности, а самой реальностью. Поэтому этот слайд нужен как вскрытие скрытого эталона. Мы должны показать: когда ты говоришь «LLM врёт», «LLM ненадёжна», «LLM нельзя доверять», «LLM ошибается», ты часто измеряешь её старым стандартом машины исполнения. Иногда это правильно. Если тебе нужен факт, источник, расчёт, правовая точность, медицинская рекомендация — да, нужна проверка, и старый стандарт частично возвращается. Но если ты хочешь породить новый ход мысли, испытать постановку задачи, увидеть альтернативы, подготовить защиту, старая рамка оказывается слишком узкой. Значит, старую машинность не надо выбрасывать. Её нужно локализовать. Она важна, но она не должна быть центром всего мышления о LLM. Код, логика, вычисление и исполнение — это мощный режим. Но LLM требует другой оптики. --- # **Слайд 9C. П** ## **Текст для выступления \+ комментарии для сборки** ### Теперь можно сформулировать центральный разрыв. Если мы держим старую машинность как единственную норму, LLM неизбежно выглядит плохой версией уже знакомых инструментов. Плохим поисковиком, потому что может выдумать источник. Плохим справочником, потому что не гарантирует факт. Плохим калькулятором по текстам, потому что не всегда воспроизводит один ответ. Плохим кодом, потому что вместо однозначного исполнения даёт вариативность. Плохим экспертом, потому что может уверенно сказать неправильное. И всё это частично правда. Но частичная правда иногда опаснее полной ошибки. Потому что она закрывает главный вопрос: а что LLM делает хорошо именно потому, что она не поисковик, не код и не справочник? Поисковик хорош там, где нужно найти уже существующий документ, ссылку, источник, страницу, фрагмент. Код хорош там, где нужно исполнить заранее заданную процедуру. Калькулятор хорош там, где есть формализованная операция и проверяемый результат. Справочник хорош там, где есть устойчивый корпус проверенных сведений. Но в реальной интеллектуальной работе огромная часть нагрузки находится не там. Студенту часто нужно не найти один ответ, а понять, какая у него вообще проблема. Не получить факт, а увидеть альтернативные постановки. Не исполнить алгоритм, а собрать ход, которого ещё нет. Не подтвердить уже выбранное, а испытать его слабые места. Не получить красивый текст, а обнаружить, где текст подменяет аргументацию. Не найти статью, а понять, какие линии литературы вообще релевантны и почему. Не узнать, «правильно ли», а увидеть, какие ещё возможны способы думать. Вот здесь LLM оказывается сильной. Она работает с полем возможных продолжений, переформулировок, связок, позиций, жанров, аргументов, возражений. Её сила не в том, что она всегда правильно отвечает. Её сила в том, что она может расширить пространство ходов. Для данной задачи, для данного студента, для данной темы она может породить мысль, которой ещё не было в его горизонте. Важно: «новая» здесь не значит абсолютно новая для человечества. Это не Нобелевская премия из промпта. Новая — для данного субъекта и данной задачи. Студент видел тему как локальный расчёт детали. Модель помогает увидеть её как проблему режима отказа, как вопрос применимости в другой системе, как конфликт требований, как материал для другой защиты. Это уже новизна в образовательном смысле: у студента появляется ход, которого раньше не было. Поэтому LLM не надо оценивать только по тому, насколько она похожа на старые инструменты. Если тебе нужен точный источник, используй поиск и проверку. Если нужна формальная процедура, используй код. Если нужен расчёт, используй расчёт. Но если нужно породить и испытать варианты хода мысли, LLM открывает другой класс работы. И это не значит, что LLM можно не проверять. Наоборот, проверять нужно ещё жёстче. Но проверять надо не только факты, а качество хода: что именно модель предложила, какую рамку сместила, какие альтернативы открыла, где усилила, где наврала, где красиво замаскировала пустоту. Работа с LLM — это не доверие машине, а управление полем вариантов. Пока студент говорит: «для серьёзной работы LLM ненадёжна», он чаще всего имеет в виду: «она ненадёжна как справочник окончательных ответов». И это разумно. Но для серьёзной работы она может быть нужна не как справочник. Она может быть нужна как среда разработки, верификации, испытания и отбора новых ходов. Это совсем другая роль. Главный поворот этого слайда: LLM не плохой поисковик и не плохой код. Она плоха, когда её используют вместо них. Но она сильна там, где нужно работать не с уже данным, а с ещё не собранным. --- # **Слайд 9D. Я** ## **Текст для выступления \+ комментарии для сборки** ### Чтобы окончательно выйти из старой рамки, нужно сказать про язык. Потому что LLM — это не просто модель, которая «пишет текст». Она обучена на огромном поле языковых режимов. А язык принципиально отличается от кода. Код — это крайний режим текста, где интерпретация почти устранена ради исполнения. Если строка кода допускает много равноправных прочтений, это не богатство смысла, а источник ошибки. Код должен быть понят машиной достаточно однозначно, чтобы перейти к действию. Естественный язык устроен иначе. Его смысл зависит от контекста, жанра, адресата, позиции, цели, масштаба, дисциплины, системы значимостей. Одна и та же фраза может работать по-разному в научной статье, разговоре, правовом документе, инструкции, лекции, романе, техническом задании, методологическом разборе. И дело не только в стиле. Меняется логика значимого. Но из этого не следует, что язык — это хаос. Это важнейший момент. Когда мы говорим «текст не код», нельзя скатиться в романтическую банальность: код строгий, язык свободный. Нет. Язык тоже имеет порядок. Просто это другой тип порядка: многоуровневый, контекстный, жанровый, дисциплинарный, позиционный, иногда почти кодоподобный, иногда открытый и творческий. Техническое задание, закон, инструкция, научная статья, философский трактат, письмо студенту, рецензия, диалог, художественный текст — всё это язык. Но степень жёсткости у них разная. В одном режиме язык приближается к коду: инструкция, спецификация, протокол. В другом — открывает пространство интерпретации: эссе, философский аргумент, исследовательская постановка, проектная гипотеза. В третьем — работает как позиционная сцена: защита, спор, рецензирование, обсуждение. LLM обучена не на одной формальной системе вывода, а на этом поле языковых режимов. В её корпусе есть код, логические задачи, научные статьи, инструкции, переписки, объяснения, споры, романы, документация, отчёты, учебники, форумы. Поэтому её нельзя описать как чистый механизм логического вывода. Она умеет входить в разные языковые режимы: где\-то быть ближе к коду, где\-то к справке, где\-то к аргументации, где\-то к симуляции позиции, где\-то к генерации альтернатив. И вот здесь открывается педагогическая задача. Студент должен научиться не просто «писать промпты», а выбирать режим языка. Он должен понимать, что просит от модели: справку, критику, рецензию, оппонента, перевод между позициями, поиск дыр, генерацию альтернатив, имитацию защиты, структурирование ТЗ, объяснение ошибки в коде. Каждый режим требует другого обращения. Если студент не различает режимы языка, он всё сводит к «ответу». А ответ — это слишком бедная единица. В сильной работе с LLM единицей становится ход: постановка, возражение, уточнение, перевод, рамка, альтернатива, проверка, версия, отбор. Поэтому слайд должен зафиксировать: язык не хаос и не код. Это поле режимов. LLM работает внутри этого поля. И наша задача — научить студента управлять режимами, а не просто просить модель «ответить нормально». --- # **Слайд 9E. L** ## **Текст для выступления \+ комментарии для сборки** ### Теперь можно точнее назвать, что такое LLM в той оптике, которая нам нужна для образования и инженерной работы. Это вероятностная текстовая среда возможных ходов. Слово «вероятностная» здесь часто понимают слишком плоско. Как будто модель просто кидает кубик и выбирает следующее слово. Тогда кажется, что вероятностность — это дефект: хотелось бы точности, а получили случайность. Но это неверное понимание. Вероятностность LLM — это не чистый произвол и не хаос. Это организация поля возможных продолжений, где одни ходы в данном контексте сильнее, другие слабее, одни уместнее, другие менее уместны, одни открывают мысль, другие закрывают её, одни воспроизводят банальность, другие смещают рамку. В старой кодовой логике есть одна допустимая траектория исполнения. В языковой вероятностной среде есть множество возможных продолжений. Это не значит, что все они равноправны. Контекст, жанр, роль, инструкция, корпус, стиль, предыдущие фразы, дисциплина, задача — всё это меняет веса возможных ходов. Поэтому модель не просто «отвечает». Она продолжает ситуацию в одном из возможных направлений. Вот почему промптинг в сильном смысле — это не искусство задавать красивые вопросы. Это способ настраивать поле возможных ходов. Ты задаёшь роль, контекст, критерий, ограничения, материалы, позицию, жанр, проверку, и тем самым меняешь не «ответ», а пространство возможных продолжений. Модель начинает двигаться в другой зоне поля. Для студента это критически важно. Если он пишет: «расскажи про мою тему», модель даёт общий ответ. Если он пишет: «покажи три скрытые проблемы моей темы, оцени, какая из них лучше выдержит защиту, и сформулируй возражения комиссии», он запускает совсем другой режим. Он не получает готовую истину. Он строит поле вариантов, которое потом должен испытать и отобрать. Поэтому LLM — это не машина единственного пути. Это машина работы с возможным. Но именно поэтому она требует нового типа ответственности. Если модель может породить много осмысленных продолжений, студент должен уметь различать: что здесь пустое, что сильное, что проверяемое, что красивое, но слабое, что фактически неверное, что открывает новый ход, что только маскирует старый. Нельзя просто радоваться, что модель «предложила идеи». Идей она предложит сколько угодно. В этом смысле она может производить интеллектуальный мусор быстрее, чем университет успевает открывать новые программы. Сила не в количестве идей. Сила в управлении полем: какие альтернативы мы запросили, по каким критериям проверили, какие отбросили, какие усилили, какие встроили в работу. Поэтому главная формула: LLM работает не как машина правильного ответа, а как вероятностная текстовая среда возможных ходов. И образовательная задача — научить студента входить в эту среду не как потребитель, а как оператор. На этом слайде важно удержать равновесие. Мы не романтизируем модель. Она ошибается, выдумывает, сглаживает, может производить банальность, может льстить запросу, может уверенно вести в пустоту. Но это не отменяет её силы. Это задаёт условия работы с ней: порождение, испытание, селекция, проверка, присвоение. То есть LLM даёт не готовую мысль, а материал для работы мысли. И в этом её образовательная мощность. --- # **Слайд 9F. С** ## **Текст для выступления \+ комментарии для сборки** ### **Текст для произнесения** Теперь можно вывести главный образовательный результат этой вставки. Если LLM — это вероятностная текстовая среда возможных ходов, то студент больше не должен быть потребителем ответов. Он должен стать оператором генерации, испытания и селекции новизны. Это звучит сложно, но на практике всё довольно ясно. Студент должен уметь вывести модель в режим порождения сильных альтернатив. Потом испытать эти альтернативы: по критериям, по фактам, по логике защиты, по требованиям дисциплины, по инженерным ограничениям, по исследовательской проверяемости. Потом отобрать то, что действительно усиливает работу. И наконец присвоить результат: встроить его в собственный ход, понять, защитить, проверить, не потерять авторство. Это принципиально отличается от режима «получить ответ». В режиме ответа студент остаётся пассивным или полупассивным. Он спрашивает, получает, вставляет, слегка редактирует. В режиме оператора он управляет полем: задаёт условия, производит варианты, сталкивает позиции, ищет слабые места, требует возражений, проверяет, отбрасывает, усиливает. Он не делегирует мышление машине, а организует человеко-машинный контур мышления. Для ВКР и инженерной работы это особенно важно. ВКР редко проваливается только потому, что студент не нашёл информацию. Чаще проблема глубже: тема плохо поставлена, объект и предмет смешаны, проблема не выявлена, гипотеза слабая, структура скачет, аргументация держится на общих словах, литература собрана без линии, защита не продумана, инженерный результат не переведён на язык разных участников. LLM может помочь именно здесь — если её правильно использовать. Не «сделай обзор литературы», а «покажи, какие три линии литературы по-разному задают мою проблему». Не «напиши актуальность», а «проверь, где моя актуальность является административной имитацией». Не «улучши текст», а «найди скачки в аргументации между главами». Не «подготовь речь», а «смоделируй пять жёстких вопросов комиссии и проверь, где я не выдержу». Не «напиши вывод», а «покажи, какой вывод действительно следует из результатов, а какой я пытаюсь притянуть». Это и есть операторская позиция. Студент не верит модели и не боится модели. Он работает с ней. Он понимает, что модель может дать новые ходы, но не освобождает его от проверки. Он понимает, что модель может расширить поле, но не выбирает за него смысл. Он понимает, что модель может помочь увидеть слабое место, но не заменяет его ответственности. Здесь появляется новая образовательная компетенция. Не «уметь пользоваться ChatGPT». Это слишком бедно. Нужно уметь ставить модель в продуктивный режим, получать варианты, различать их качество, проверять на факты и логику, удерживать авторство, фиксировать следы работы, объяснять, что было сделано человеком и что машиной. И это возвращает нас к теме экспериментов. Если преподаватель хочет сделать курс с LLM, он должен проектировать не просто доступ к модели, а формирование этой операторской позиции. Какие задания заставляют студента порождать альтернативы? Какие требуют испытания? Где он должен объяснить выбор? Где фиксируются отброшенные варианты? Где виден его вклад? Где LLM помогает подняться выше, а где даёт возможность спрятаться? Главная формула: студент должен стать не потребителем ответов, а оператором генерации, испытания и селекции новизны. И если после первых занятий студент всё ещё думает: «LLM полезна для справки, но для серьёзной работы ненадёжна», поворот не состоялся. Если он начинает спрашивать: «какие здесь ещё есть сильные ходы, что я не вижу, где мой самый слабый переход, какая постановка лучше выдержит защиту», значит, поворот произошёл. И только после этого можно всерьёз говорить о конфигураторах, симуляторах, агентах, workflow и ИИ-архитектуре эксперимента. --- --- # **Слайд 10\. LLM как конфигуратор и симулятор** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** мягко ввести CAD/CAE, не превращая это в отдельную инженерную лекцию. **Заголовок:** **LLM как конфигуратор и симулятор** **Содержание:** Две операции. **Сконфигурировать ситуацию:** роль; контекст; материалы; критерии; ограничения; формат; позиция; стиль. **Прогнать ситуацию:** альтернативы; возражения; сбои; ошибки модели; слабые места; недобросовестное использование. **Главная формула:** **Промптинг здесь не “искусство вопросов”, а минимальный способ проектировать и тестировать интеллектуальную ситуацию.** --- ## **Текст для выступления \+ комментарии для сборки** ### **Текст для произнесения** Теперь нужно сделать следующий шаг. Если LLM входят в язык университетской работы, то промптинг нельзя понимать как «искусство задавать вопросы». Это слишком мелкая рамка. Да, можно учиться задавать хорошие вопросы модели. Но в сильных образовательных экспериментах промптинг — это минимальный способ проектировать интеллектуальную ситуацию. Что значит «интеллектуальная ситуация»? Это не просто запрос. Это роль, контекст, материалы, критерии, ограничения, формат, позиция, стиль, допустимые и недопустимые действия. Когда преподаватель пишет промпт для ИИ-персоны курса, он фактически проектирует участника образовательной ситуации. Когда он пишет промпт для критика эссе, он задаёт критерии, границы помощи, способ обратной связи. Когда он пишет промпт для симулятора заказчика, он задаёт позицию, интересы, ограничения, тип возражений. Когда он пишет промпт для исследовательского собеседника, он задаёт, как модель должна работать с вопросом, гипотезой, источниками, сомнением. В этом смысле LLM можно понимать как конфигуратор. Мы конфигурируем ситуацию: кто говорит, откуда говорит, по каким материалам, в каком жанре, с какими критериями, что разрешено, что запрещено, где нужно остановить студента, где нужно задать вопрос, где не давать готовый ответ. Это похоже на очень мягкую форму проектирования среды. Не CAD в техническом смысле, не инженерная система проектирования деталей, а скорее минимальный CAD интеллектуальной ситуации: мы задаём форму будущего взаимодействия. Но LLM — ещё и симулятор. Мы можем не только сконфигурировать роль, но и прогнать ситуацию. Что будет, если студент попытается списать? Что будет, если модель начнёт давать готовые ответы? Где критик эссе станет соавтором вместо критика? Где ИИ-персона превратится в справочник? Где исследовательский ассистент начнёт придумывать источники? Где симулятор заказчика будет слишком добрым и перестанет быть заказчиком? Где инструкция конфликтует с образовательной целью? Это очень важный ход. Промпт можно использовать не только для получения ответа, но и для тестирования сценария. Мы можем прогонять альтернативы, возражения, сбои, ошибки модели, слабые места, недобросовестное использование. То есть LLM становится ещё и чем-то вроде CAE — опять же мягко, без превращения в инженерную лекцию. Мы не только проектируем ситуацию, но и проверяем, как она ломается. Пример. Преподаватель хочет сделать ИИ-критика студенческого эссе. В слабой версии промпт будет такой: «Оцени эссе по критериям». Модель, конечно, оценит. Может быть, даже красиво. Но образовательная ситуация не задана. В сильной версии нужно определить: критик не переписывает текст; не даёт финальную версию; задаёт вопросы; указывает слабые места аргумента; различает тезис, основание, пример, вывод; требует от студента новой версии; фиксирует изменения. Потом этот сценарий надо протестировать: что будет, если студент попросит переписать за него? Что будет, если он даст пустой текст? Что будет, если он спорит? Что будет, если модель начинает слишком помогать? Другой пример: ИИ-персона исторического автора. Сконфигурировать — значит задать корпус, позицию, ограничения, стиль, тип вопросов, границу между реконструкцией и выдумкой. Прогнать — значит проверить, не начинает ли персона фантазировать, не отвечает ли современными клише, не превращается ли в экскурсовода, не теряет ли образовательную функцию. Третий пример: проектный симулятор. Сконфигурировать — значит задать роль заказчика, ограничения, интересы, конфликт требований, критерии принятия решения. Прогнать — значит проверить, как команда будет обходить трудности, где симулятор слишком мягкий, где слишком абстрактный, где не создаёт настоящего напряжения. Здесь главный тезис: промптинг в образовательном эксперименте — не искусство красиво попросить модель. Это способ проектировать и тестировать интеллектуальную ситуацию. И если мы так его понимаем, то промпт становится не частным навыком, а частью педагогической технологии. Но надо быть осторожным. Мы не должны сказать, что всё можно решить хорошим промптом. Это ещё одна форма магии: раньше была методическая, теперь промптовая. Хороший промпт не заменяет педагогическую гипотезу, сценарий деятельности, материалы, критерии, следы, проверку, инфраструктуру. Он только минимальная форма конфигурации. В сильном проекте промпт связан с RAG, материалами курса, логированием, интерфейсом, ролями преподавателя и студента, дизайном эксперимента. Поэтому вопрос к участникам: какую ситуацию вы конфигурируете? Не какой вопрос задаёте модели, а какую интеллектуальную ситуацию создаёте. Кто в ней действует? В какой роли ИИ? По каким материалам? С какими ограничениями? Как она может сломаться? Как студент может использовать её недобросовестно? Как модель может выйти из роли? Какие следы покажут, что ситуация сработала? Вот это и есть переход от промптинга как ремесла вопроса к промптингу как проектированию ситуации. ### **Пример для пояснения** «Не “помоги студенту написать эссе”, а: “будь критиком аргументации, не переписывай текст за студента, задавай вопросы по критериям, требуй основания, фиксируй, что студент изменил между версиями”. Это уже не вопрос к базе. Это конфигурация образовательного взаимодействия». --- --- # **Слайд 11\. ИИ как процесс: агенты, workflow, пайплайны, кодинг-агенты** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать, что ИИ — это уже не только чат, но связка действий и инструментов. **Заголовок:** **ИИ как процесс: агенты, workflow, пайплайны** --- ## **Текст для выступления \+ комментарии для сборки** ### После LLM как конфигуратора нужно показать ещё один слой: ИИ всё чаще существует не как одиночный чат, а как процесс. Это особенно важно, потому что многие образовательные и исследовательские задачи не сводятся к одному ответу модели. Нужно прочитать материалы, извлечь данные, найти фрагменты, вызвать модель в нужной роли, проверить результат, сохранить следы, оформить отчёт, передать преподавателю, обновить базу, подготовить следующий шаг. Это уже процессный слой: RAG, базы знаний, workflow, API-интеграции, кодинг-агенты, автоматические проверки, логирование, генерация отчётов, работа с файлами. Здесь ИИ становится не просто собеседником, а элементом цепочки действий. Простейший пример — бот по материалам курса. В слабой версии это просто чат: студент задаёт вопрос, модель отвечает. В более сильной версии есть база материалов, поиск по фрагментам, привязка ответа к источнику, ограничение фантазий, лог взаимодействия, отчёт преподавателю о типовых затруднениях. Это уже не просто LLM, а процесс: студент спросил → система нашла релевантные материалы → модель сформулировала ответ в заданной роли → ответ связан с источником → след сохранился → преподаватель увидел карту вопросов. Другой пример — исследовательский ассистент. Одиночный чат может пересказать тему. Процессный контур может сделать другое: принять корпус источников, выделить основные позиции, сгруппировать споры, найти пустоты, предложить варианты исследовательского вопроса, проверить гипотезы, зафиксировать отклонённые варианты, подготовить краткий отчёт. Здесь важна цепочка: прочитал → извлёк → сгруппировал → проверил → предложил → оформил. И на каждом этапе можно задавать роль, критерий, ограничение, проверку. Третий пример — проектная студия. Команда работает над решением. Процессный ИИ может собрать требования, зафиксировать ограничения, сгенерировать альтернативы, провести предварительную критику, оформить спецификацию, проверить риски, подготовить вопросы к заказчику. Это уже не «чат помог», а цепочка проектного действия. Кодинг-агенты показывают этот слой особенно резко. Они не просто отвечают на вопрос о коде, а могут читать файлы, предлагать изменения, запускать проверки, исправлять ошибки, оформлять коммиты, вести процесс разработки. В образовании это важно не потому, что всем надо срочно учить кодинг-агентов, а потому, что они показывают общий принцип: ИИ начинает входить в цепочки работы, где есть файлы, проверки, версии, результаты, обратная связь. Но здесь есть риск обратной редукции. Мы можем так увлечься workflow, агентами, пайплайнами и API, что снова потеряем LLM как текстовую и смысловую среду. Начнём думать, что всё настоящее — это только исполняемый модуль, цепочка действий, автоматизация, интеграция. А всё, что происходит в диалоге, роли, жанре, интерпретации, — будто бы вторично. Это неправильно. Процессный слой очень важен. Без него нельзя строить нормальные RAG-системы, сборщики следов, исследовательские пайплайны, проектные студии, кампусные сервисы. Но он не исчерпывает LLM. Текстовая агентность не равна исполняемому модулю. В сильных образовательных экспериментах есть и процессная цепочка, и семантическая роль. Например, ИИ-персона курса может быть технически встроена через RAG и логи, но её образовательная сила зависит от позиции, жанра, способа задавать вопросы, удержания роли. Исследовательский ассистент может работать через workflow, но его качество зависит от того, как он критикует гипотезу и различает слабые основания. Поэтому на этом слайде нужно удержать двойную мысль. С одной стороны, ИИ — это уже не только чат. Он становится процессом, пайплайном, связкой инструментов. С другой — процессный слой не отменяет смысловой. Мы не должны загнать LLM обратно в старую вычислительную схему, где всё — модуль, вход, выход, контракт, проверка. Это часть правды, но не вся правда. Университетский вопрос здесь такой: какие цепочки работы в вашем эксперименте должны быть собраны? Где нужен RAG? Где база знаний? Где логирование? Где автоматическая проверка? Где отчёт? Где работа с файлами? Где человек должен оставаться в контуре? Где модель должна быть не просто ответчиком, а участником процесса? И одновременно второй вопрос: какая часть этого процесса является технической, а какая смысловой? Где нужна инженерия, а где педагогическая роль? Где нужна автоматизация, а где удержание диалога? Где агент должен действовать, а где обязан остановиться? Это и есть переход к следующему слайду: текст не равен коду. LLM нельзя понимать только как исполняемый модуль. --- --- # **Слайд 12\. Текст ≠ код: LLM как семантическая и агентная среда** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** не дать свести LLM к старой вычислительной схеме. **Заголовок:** **Текст ≠ код: LLM нельзя понимать только как исполняемый модуль** ## **Текст для выступления \+ комментарии для сборки** ### Теперь нужно сделать очень важное различение. После разговора про workflow, RAG, агентов, API и кодинг-агентов легко захотеть всё привести к привычной инженерной схеме: вход, выход, инструкция, контракт, модуль, корректность, контроль, pipeline. Это нужная схема. Без неё нельзя строить устойчивые системы. Но если мы целиком загоняем LLM в эту схему, мы теряем главное. LLM работают не только как исполняемый модуль. Они работают в текстовой, семантической, ролевой среде. А текст — это не код. Кодовая логика устроена так: есть инструкция, есть контракт, есть вход и выход, есть модуль, есть корректность, есть проверка, есть контроль. Мы хотим, чтобы код исполнялся предсказуемо. Если он исполняется слишком творчески, это обычно не повод для радости. Когда бухгалтерская система начинает проявлять творческое отношение к налогам, у организации быстро появляется философский опыт конечности. Текстовая логика другая. В тексте есть контекст, роль, жанр, позиция, интерпретация, недоопределённость, перенос смысла, творческий ход, со-настройка. Один и тот же текст может быть прочитан по-разному в разных рамках. Вопрос может нести не только запрос информации, но и позицию, затруднение, попытку уклонения, страх, незнание, приглашение к диалогу. Ответ может быть не только результатом, но и ходом в сцене. LLM действуют именно в промежутке между формализацией и смыслом. Они достаточно формализуемы, чтобы их можно было включать в процессы, задавать инструкции, ограничивать, проверять, связывать с базами. Но они достаточно семантически гибки, чтобы быть тьютором, критиком, персоной, собеседником, симулятором, редактором, оппонентом. И вот эта промежуточность — не дефект, а источник образовательной мощности. Очень часто хочется сказать: вариативность LLM — это проблема. Модель отвечает не всегда одинаково. Она может сдвинуть акцент. Может интерпретировать. Может не попасть. Может породить лишнее. С инженерной точки зрения это неудобно. Но в образовании часть этой вариативности может быть ценной. Образовательная ситуация не всегда требует одного правильного выхода. Иногда нужно породить альтернативы, увидеть разные позиции, столкнуть интерпретации, заставить студента уточнить мысль, не дать ему спрятаться за готовую формулу. Конечно, это не значит, что нужно радоваться ошибкам модели. Галлюцинации не становятся педагогикой от того, что мы назвали их творческим ходом. Но и обратное неверно: нельзя требовать от LLM быть только детерминированным модулем. Тогда мы потеряем то, ради чего они особенно интересны в образовании: роль, диалог, интерпретацию, сцену, со-настройку, интеллектуальное сопротивление. Возьмём ИИ-персону курса. Если понимать её как кодовый модуль, мы спросим: какой вход, какой выход, какие инструкции, какие ограничения. Это нужно. Но этого мало. Нужно ещё спросить: какую позицию она удерживает? Какой жанр диалога ведёт? Где она должна сопротивляться студенту? Где должна молчать? Где должна не давать ответ? Где должна вернуть к тексту? Где должна различить ошибку понимания? Это уже не только контракт исполнения. Это семантическая роль. Или ИИ-критик. Как модуль он получает текст и выдаёт комментарий. Как семантическая роль он вступает в отношение со студенческой мыслью: не переписывает, не заменяет, не унижает, не льстит, а показывает слабое место, возвращает к основанию, требует следующей версии. Это разные уровни проектирования. Или исследовательский собеседник. Как workflow он может читать источники и выдавать сводку. Как семантическая среда он помогает удерживать вопрос, сомнение, альтернативу, методологическую честность, границу знания. Если мы оставим только workflow, получим быстрый обзор литературы. Если добавим роль критического собеседника, может появиться исследовательское мышление. Поэтому главная формула этого слайда: люфт, вариативность и семантическая неполная формализуемость LLM — не баг, а источник творческой и образовательной мощности. Но эту формулу нужно понимать аккуратно. Не всякий люфт полезен. Не всякая вариативность хороша. Не всякая недоопределённость продуктивна. Задача проектировщика эксперимента — не убрать люфт полностью, а сделать его педагогически работающим. Задать рамку, в которой вариативность помогает различению, а не производит кашу. Это и есть причина, почему сильный ИИ-эксперимент не может быть только инженерной автоматизацией. Он должен учитывать текстовую агентность. В нём ИИ не только исполняет команды, но участвует в распределённой человеко-машинной сборке: студент, преподаватель, материалы, модель, критерии, следы, роль, диалог. И если мы это не понимаем, мы либо делаем старую автоматизацию с новым мотором, либо получаем говорящую машину без педагогической формы. Итак: текст не равен коду. LLM нельзя понимать только как исполняемый модуль. Они требуют и инженерной дисциплины, и семантического проектирования. Именно на этом стыке появляются сильные образовательные эксперименты. ### **Главная формула** **Люфт, вариативность и семантическая неполная формализуемость LLM — не баг, а источник творческой и образовательной мощности.** --- --- # **Слайд 13\. Слои не сменяют друг друга, а накладываются** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** собрать предшествующие слайды в одну многослойную карту. **Заголовок:** **Слои не сменяют друг друга, а накладываются** **Главная формула:** **Сильный ИИ-эксперимент не выбирает между кодом и текстом. Он собирает их в человеко-машинную сеть.** ## **Текст для выступления \+ комментарии для сборки** ### Теперь нужно собрать всё, что было в предыдущих слайдах. Мы прошли несколько типов ИИ: аналитика и ML как видимость состояния и обратная связь; символический ИИ как явная структура экспертного действия; foundation и domain models как работа с предметными пространствами; LLM как язык интеллектуальных операций; workflow, RAG и агенты как процессный слой; и наконец различение текстовой и кодовой логики. Важно не понять это как историческую смену эпох. Не было так, что сначала были правила, потом они умерли, потом пришли нейросети, потом умерли они, потом пришли LLM, потом пришли агенты и всех победили. Это плохая мифология, удобная для техно-новостей. В реальных образовательных и университетских экспериментах слои не сменяют друг друга. Они накладываются. Сильный ИИ-эксперимент почти всегда многослоен. В нём может быть формализуемый слой: аналитика, база материалов, RAG, workflow, API, логирование. Может быть семантический слой: роль, персона, критик, тьютор, исследовательский собеседник, творческий агент. Может быть институциональный слой: курс, лаборатория, проект, семинар, R\&D, портфель, платформа. И если мы видим только один слой, мы недопонимаем проект. Возьмём ИИ-персону курса. На поверхности это может выглядеть как LLM. Но сильная ИИ-персона — это не просто чат. В формализуемом слое у неё могут быть материалы курса, база знаний, RAG, сценарии, логирование, ограничения. В семантическом слое — позиция, жанр, голос, педагогическая функция, способ задавать вопросы, критика ошибок. В институциональном слое — место в курсе, роль преподавателя, методическая поддержка, возможность повторного использования, связь с портфелем экспериментов. Если убрать любой слой, персона слабеет. Без формального слоя она фантазирует. Без семантического — становится справочником. Без институционального — остаётся игрушкой одного курса. Возьмём исследовательский ассистент. Формализуемый слой: корпус источников, поиск, извлечение, проверка, отчёт. Семантический слой: критика гипотезы, различение вопроса, работа с сомнением, интерпретация. Институциональный слой: научно-исследовательский семинар, лаборатория, аспирантура, публикационный контур, R\&D-повестка. Если это только workflow, он будет быстро производить обзоры. Если это только разговор, он может быть интересным, но плохо проверяемым. Если нет институционального слоя, результат никуда не встраивается. Возьмём governance и добросовестность. Формализуемый слой: логи, версии, раскрытие использования, правила, политики, разрешённые инструменты. Семантический слой: понимание вклада, ответственности, присвоения, различение помощи и подмены. Институциональный слой: правила курса, политика университета, оценивание, портфель экспериментов. Если оставить только правила, получим контроль. Если оставить только разговор о честности, получим моральную проповедь. Если соединить слои, появляется новая архитектура доказательства действия. Поэтому главный тезис: сильный ИИ-эксперимент не выбирает между кодом и текстом. Он собирает их в человеко-машинную сеть. И здесь слово «сеть» важно не как красивая метафора, а как описание распределения ролей. Действуют не только студент и преподаватель. Действуют материалы, модель, база, сценарий, интерфейс, лог, критерий, лаборатория, платформа, семинар. Одни элементы человеческие, другие машинные, третьи организационные. Образовательный эффект появляется не от того, что мы добавили ИИ, а от того, что мы пересобрали сеть действия. Это также возвращает нас к задаче курса. Мы не просто обучаем преподавателей пользоваться инструментами. Мы помогаем им проектировать эксперименты в многослойной среде. Участник должен спросить: какой у меня формализуемый слой? Какие данные, материалы, RAG, логи, workflow? Какой семантический слой? Какая роль ИИ, какой жанр, какая позиция, какой тип обратной связи? Какой институциональный слой? Это курс, лаборатория, проект, семинар, портфель, платформа? Где мой проект находится в общей карте? И вот здесь становится видно, зачем нам были предыдущие слайды. Если человек говорит «я хочу тьютора», мы спрашиваем: какой формальный слой у тьютора? На каких материалах он работает? Какие следы оставляет? Какая у него семантическая роль? Он объясняет, спрашивает, критикует, удерживает затруднение? Как он встроен институционально? Это обязательный элемент курса, добровольная помощь, часть эксперимента, часть портфеля, прототип платформы? Если человек говорит «я хочу исследовательского ассистента», мы спрашиваем то же самое. Если «хочу оценивать с ИИ» — то же самое. Если «хочу проектный симулятор» — то же самое. Слои не сменяют друг друга, а накладываются. Это главная сборка первой большой части про поле ИИ. И после неё мы можем перейти к следующему вопросу: если слои различены, то на каком масштабе находится эксперимент? Он оптимизирует операцию, поддерживает преподавателя, меняет действие студента, формирует функцию, перестраивает курс или становится элементом университетской среды? Но перед этим важно зафиксировать: сильный проект — это не «чатик плюс надежда». Это сборка формализуемого, семантического и институционального слоёв. ### **Комментарии для сборки слайда** Слайд должен быть итоговой многослойной картой. Три слоя: формализуемые слои — аналитика, базы, RAG, workflow, API, логирование; семантические слои — роль, персона, критик, тьютор, исследовательский собеседник, творческий агент; институциональные слои — курс, лаборатория, проект, семинар, R\&D, портфель, платформа. В центре пример: «ИИ-персона \= LLM \+ материалы/RAG \+ сценарий \+ следы \+ преподавательская интерпретация \+ место в курсе». Главная формула: «Сильный ИИ-эксперимент не выбирает между кодом и текстом. Он собирает их в человеко-машинную сеть». Визуально — не три списка, а наложенные слои/стек. --- --- # **Слайд 14\. Задание 1: какой ИИ фактически подразумевает ваш эксперимент?** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** первое рабочее задание. Оно не про уровень и не про паттерн, а про тип машинности. **Заголовок:** **Задание 1\. Какой ИИ фактически подразумевает ваш эксперимент?** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь мы можем сделать первое рабочее задание. До этого момента мы не просили вас сразу улучшать свои проекты. Это было бы преждевременно. Сначала надо было различить поле: аналитика, символический ИИ, предметные модели, LLM, workflow, агенты, текстовая и кодовая логика, формализуемые, семантические и институциональные слои. Теперь можно вернуться к вашей исходной идее и задать ей первый нормальный вопрос: какой ИИ она фактически подразумевает? Обратите внимание: вопрос не «каким сервисом вы будете пользоваться». Это не архитектурный вопрос. Сервис — это поверхность. Сегодня он один, завтра другой, послезавтра университет закупил третий, а потом кто-то забыл оплатить лицензию, и вся цифровая трансформация пошла пить чай. Нам важнее понять функцию ИИ. Он у вас кто? Справочник? Тьютор? Персона? Критик? Генератор вариантов? Оценщик? Симулятор? Навигатор по материалам? Аналитический слой? Сборщик следов? Research assistant? Workflow? RAG по корпусу курса? Процессный агент, который читает, извлекает, проверяет, оформляет? Обычно проект на первом шаге звучит так: «хочу использовать ИИ для помощи студентам», «хочу сделать бота по курсу», «хочу персонализировать обучение», «хочу автоматизировать обратную связь». Это нормальная стартовая формулировка, но пока она слишком общая. Она говорит о желании, а не об архитектуре. В образовательном эксперименте нам нужно понять, какая искусственная функция нужна, чтобы изменилась деятельность. Допустим, вы хотите улучшить чтение сложных текстов. Это может быть LLM-пересказчик. Тогда риск очевиден: студент перестаёт читать, но начинает лучше сдавать пересказы. Это может быть тьютор, который задаёт вопросы и возвращает к фрагменту текста. Это может быть ИИ-персона автора, которая удерживает позицию и спорит с упрощениями. Это может быть критик интерпретации, который ловит типовые ошибки. Это может быть аналитический слой, который показывает, где студенты чаще всего застревают. Это разные проекты, хотя исходная проблема одна. Или вы хотите улучшить проектную работу. ИИ может быть генератором идей. Может быть симулятором заказчика. Может быть критиком требований. Может быть проверяющим ограничений. Может быть документатором решений. Может быть процессным агентом, который ведёт команду через этапы. Если вы не различаете эту роль, вы рискуете получить стандартный результат: команда делает более гладкую презентацию, а проектное мышление не меняется. Поэтому задание простое, но не лёгкое. Нужно взять свою идею и переписать её через тип ИИ и роль ИИ. Не «ИИ поможет студентам», а «ИИ выступает как критик аргументации, который не переписывает текст, а возвращает студента к тезису, основанию, примеру и выводу». Не «бот по курсу», а «ИИ-персона курса, работающая по материалам через RAG, удерживающая позицию автора и фиксирующая вопросы студента». Не «автоматизация проверки», а «контур обратной связи, который показывает типовые ошибки, версии исправлений и риск подмены работы студента». На этом этапе не нужно делать идеальную формулировку. Нужно убрать туман. Если вы пока не знаете, какой тип ИИ нужен, это тоже хороший результат. Значит, проект ещё не готов к ТЗ. И лучше понять это сейчас, чем через месяц, когда инженер спросит: «что именно должно работать?», а вы ответите: «ну, чтобы ИИ помогал». Инженер после такого обычно не плачет, но только потому, что у него уже выработалась профессиональная защита. Итак, первая рабочая рамка: какой ИИ фактически подразумевает ваш эксперимент? Что именно делает ИИ? Какую функцию он выполняет? Как это связано с гипотезой? Какие материалы, данные, сценарии, правила, следы ему нужны? Что делает человек? Где проходит граница между помощью и подменой? Это первое упражнение не про оформление. Это про честность архитектуры. ### **Проблематизация** Опасность этого задания — участники могут просто написать названия инструментов: ChatGPT, Claude, Perplexity, GigaChat. Это надо заранее пресечь. Нужно сказать: «Название сервиса не является ответом. Ответ — это роль и тип действия: критик аргументации, собеседник исторической личности, аналитик следов, навигатор по материалам, симулятор заказчика, генератор проектных альтернатив». ### **Связь со следующим блоком** После этого задания участники уже видят, что внутри их идеи может быть разный ИИ. Теперь можно задавать следующий вопрос: **на каком масштабе этот ИИ меняет образовательную, исследовательскую или проектную деятельность?** --- --- # **Слайд 15\. Шкала масштаба ИИ-эксперимента** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** ввести именно шкалу масштаба, не «модели» и не «паттерны». **Заголовок:** **Шкала масштаба ИИ-эксперимента** **Содержание:** Вертикальная шкала. 1. Оптимизация операции. 2. Поддержка преподавателя / методиста / руководителя. 3. Средство действия участника. 4. Тренажёр функции. 5. Архитектура курса / лаборатории / проектной среды. 6. Элемент новой университетской среды. **Главная формула:** **Чем выше уровень, тем больше меняется не инструмент, а организация деятельности.** --- ## **Текст для выступления \+ комментарии для сборки** ### **Текст для произнесения** Когда мы различили тип ИИ, появляется второй вопрос: на каком масштабе находится эксперимент? Это другое измерение. Тип ИИ говорит, какая машинная функция используется. Масштаб говорит, насколько глубоко меняется деятельность. Эти вещи нельзя смешивать. Один и тот же LLM может работать на маленьком масштабе: помочь преподавателю быстрее подготовить примеры. Может работать на среднем масштабе: стать тьютором, с которым студент проходит цикл попыток и обратной связи. Может работать на большом масштабе: стать частью архитектуры курса, где меняются роли преподавателя, студента, методиста, инженера, аналитического контура. Может стать элементом кампусной платформы или портфеля экспериментов. Технология может быть та же, масштаб изменения — разный. Поэтому нам нужна шкала масштаба. Не шкала «крутости». Не рейтинг зрелости. Не управленческая лестница, по которой все должны карабкаться вверх, чтобы выглядеть прилично. Это шкала глубины изменения деятельности. Первый уровень — оптимизация операции. ИИ помогает быстрее написать, найти, перевести, сгенерировать, оформить. Это полезно, но образовательный процесс может почти не измениться. Второй уровень — поддержка преподавателя, методиста, руководителя. ИИ помогает готовить материалы, варианты заданий, критерии, комментарии, планы занятий, подборки кейсов. Здесь меняется труд преподавателя, но не обязательно меняется действие студента. Третий уровень — средство действия участника. Студент, исследователь, проектная команда начинают использовать ИИ внутри собственной работы: читать, писать, анализировать, проверять, программировать, проектировать. Здесь уже появляется вопрос: формируется ли новая способность или просто улучшается продукт? Четвёртый уровень — тренажёр функции. ИИ не просто помогает, а создаёт цикл формирования действия: попытка, критерий, обратная связь, исправление, новая попытка, след, рефлексия. Это важный образовательный уровень. Пятый уровень — архитектура курса, лаборатории или проектной среды. Здесь проектируется не один инструмент, а распределение ролей: студент, преподаватель, ИИ-персона, тьютор, критик, аналитический слой, инженерный контур, материалы, следы, оценивание. Шестой уровень — университет как поле оркестрации интеллектов. Это уже не отдельный курс, а вопрос платформы, портфеля, R\&D, governance, новых функций преподавателя, исследовательских и проектных сред. Повторю: низкий уровень не плохой. Плохо другое — заявлять высокий уровень и реализовывать низкий. Когда говорят «перепроектирование образования», а делают генератор тестов. Когда говорят «ИИ-персона», а делают справочник. Когда говорят «research pipeline», а получают пересказ литературы. Когда говорят «добросовестность», а вводят галочку «использовал ИИ». Проблема не в скромности. Проблема в нечестном масштабе. Эта шкала нужна, чтобы участник мог сказать: сейчас мой эксперимент на уровне 2, но его можно усилить до уровня 4\. Или: я думал, что делаю уровень 5, но пока у меня уровень 1\. Это не провал. Это нормальный результат различения. Университетские проекты часто ломаются не потому, что люди мало хотят, а потому что они не понимают цену масштаба. Уровень 5 требует сценария, ролей, следов, инфраструктуры, ответственности. Уровень 6 требует ещё и портфеля, политики, платформы, управления, R\&D. Поэтому шкала масштаба — это не украшение. Это способ не сойти с ума от слова «трансформация». --- --- # **Слайд 16\. Уровни 1–2: локальная польза без трансформации процесса** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** легитимировать простые входы, но не позволить выдать их за трансформацию. **Заголовок:** **Уровни 1–2: локальная польза без трансформации процесса** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь надо спокойно поговорить о первых двух уровнях. Их нельзя презирать. ИИ на уровне операции и поддержки преподавателя может быть очень полезен. Он экономит время, помогает готовить материалы, расширяет набор примеров, ускоряет перевод, делает черновики, помогает формулировать задания, подбирать кейсы, адаптировать тексты, готовить критерии, создавать варианты обратной связи. В реальной преподавательской жизни это не мелочь. Иногда экономия времени — это разница между живым преподавателем и человеком, который вечером смотрит в стену и уже не очень помнит, зачем он в образовании. Но надо честно понимать границу. Если ИИ только ускорил подготовку материалов, образовательный процесс мог не измениться. Если преподаватель стал быстрее делать презентации, это хорошо для преподавателя, но это ещё не эксперимент по изменению деятельности студента. Если модель сгенерировала двадцать вариантов тестов, это может быть полезно, но сама по себе генерация тестов не доказывает, что студент начал иначе мыслить. Уровень 1 — это оптимизация операции. Написать черновик, перевести текст, сократить материал, придумать примеры, оформить задание, сгенерировать вопросы. Это можно внедрять быстро, но здесь надо быть осторожным с громкими словами. Это не трансформация образования. Это повышение производительности отдельных операций. Уровень 2 — поддержка преподавателя, методиста, руководителя. Здесь ИИ помогает проектировать элементы курса: варианты заданий, рубрики, план занятия, кейсы, индивидуализированные материалы, первичные комментарии к работам, подготовку ТЗ. Это уже ближе к педагогическому дизайну, но всё ещё может оставаться внутри старого процесса. Преподаватель стал лучше подготовлен, но студент действует по-прежнему. Главная ошибка на этих уровнях — назвать удобство изменением образования. Например, преподаватель говорит: «я персонализировал обучение», потому что модель сгенерировала три версии текста разной сложности. Возможно, это шаг к персонализации. Но персонализация начинается не с трёх версий текста, а с понимания состояния студента, траектории, обратной связи, выбора дальнейшего действия. Или говорят: «я внедрил адаптивное обучение», а на деле просто дали студентам разные подсказки. Это может быть хорошо, но это ещё не адаптивный контур. Наша задача не унизить уровни 1–2. Наоборот, их надо честно использовать. Для многих преподавателей именно здесь начинается вход в ИИ. Человек перестаёт бояться инструмента, видит пользу, начинает замечать, какие операции можно делегировать. Но если мы хотим образовательный эксперимент, нужно спросить: где переход дальше? Как из поддержки преподавателя возникает изменение деятельности студента? Какие следы покажут, что это не только экономия времени? Например, если ИИ помогает преподавателю готовить задания, эксперимент может быть не про сам факт генерации заданий, а про качество новых заданий: стали ли они лучше удерживать проблемность, стали ли создавать разные траектории, стали ли точнее проверять нужную функцию. Тогда уровень 2 может стать входом в уровень 3 или 4\. Но сам по себе он остаётся уровнем 2\. Поэтому на этом слайде важно зафиксировать границу: уровни 1–2 дают локальную пользу, но не обязательно меняют образовательный процесс. Они полезны, но требуют честного называния. Мы не запрещаем маленький масштаб. Мы запрещаем масштабную риторику поверх маленького действия. ### **Пример** «Преподаватель сгенерировал 20 вариантов задач. Это уровень 1 или 2\. Но если дальше студенты проходят через адаптивный цикл, получают разные задачи по диагностике ошибок, оставляют следы попыток, а преподаватель видит карту затруднений — тогда проект может подняться выше». ### **Связь со следующим слайдом** Следующий слайд — уровни 3–4, где ИИ входит уже не только в труд преподавателя, а в действие участника и формирование функции. --- --- # **Слайд 17\. Уровни 3–4: изменение действия и формирование функции** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать переход к собственно образовательному эксперименту. **Заголовок:** **Уровни 3–4: действие участника и формирование функции** --- ## **Текст для выступления \+ комментарии для сборки** ### На уровнях 3–4 начинается образовательная серьёзность. Не потому, что первые уровни плохие, а потому что здесь ИИ входит уже не только в труд преподавателя, а в действие участника. Студент, исследователь, проектная команда начинают работать с ИИ как со средством собственной деятельности. И здесь появляется главный вопрос: ИИ помогает сформировать способность или только улучшает продукт? Уровень 3 — ИИ как средство действия участника. Студент использует ИИ, чтобы читать, писать, анализировать, кодить, проектировать, формулировать гипотезу, проверять источники, готовить аргумент, работать с данными. Это уже гораздо ближе к реальности, потому что именно так студенты и будут использовать ИИ, независимо от того, разрешили мы им или нет. Вопрос не в том, чтобы делать вид, что этого не существует. Вопрос в том, чтобы встроить это в образовательный процесс. Но уровень 3 опасен. Студент может с помощью ИИ пройти действие, а может обойти действие. Он может лучше понять текст, а может получить пересказ вместо чтения. Может научиться проверять код, а может просто получить рабочий фрагмент. Может улучшить аргумент, а может взять чужой аргумент и не суметь его защитить. Поэтому на уровне 3 всегда нужен вопрос о границе помощи и подмены. Уровень 4 — ИИ как тренажёр функции. Здесь появляется педагогически сильная форма. ИИ не просто помогает студенту выполнить задачу, а организует цикл формирования действия. Студент делает попытку. Получает обратную связь. Видит критерий. Исправляет. Делает новую попытку. Оставляет след. Рефлексирует изменение. Преподаватель может увидеть не только итоговый продукт, но и траекторию. Например, ИИ-критик эссе. На уровне 3 он помогает студенту улучшить текст. На уровне 4 он устроен так, чтобы студент проходил цикл аргументации: тезис, основание, пример, возражение, уточнение, новая версия. Он не переписывает за студента, а требует работы. Это уже тренажёр функции. Или ИИ-помощник в программировании. На уровне 3 он помогает написать код. На уровне 4 он помогает понять ошибку, объяснить причину, предложить тест, сравнить варианты, зафиксировать, что студент изменил в понимании. Не просто код работает, а студент проходит функцию отладки. Или исследовательский ассистент. На уровне 3 он помогает собрать литературу. На уровне 4 он ведёт через постановку вопроса, проверку гипотезы, операционализацию, отказ от слабых вариантов, фиксацию основания. Тогда формируется исследовательская функция, а не только обзор. Здесь появляется ключевая формула: образовательный эффект не в том, что продукт стал лучше. Образовательный эффект в том, что изменился способ действия. И это надо доказать. Поэтому уровни 3–4 требуют следов. Версии, попытки, ошибки, исправления, вопросы, возвраты к критерию, комментарии, самоотчёт. Без следов мы не знаем, что произошло. Может быть, студент научился. Может быть, просто хорошо воспользовался машиной. На этих уровнях ИИ начинает быть по-настоящему интересным для образования. Он может не снижать нагрузку, а менять её качество. Раньше студент тратил время на рутину, теперь может подняться к более сложной операции. Но это произойдёт только в хорошей архитектуре. В плохой архитектуре он просто минует работу и получит красивый результат. Поэтому вопрос к проекту: что должен делать участник с ИИ? Какой цикл действия возникает? Где попытка, где обратная связь, где критерий, где исправление, где след? Если этого нет, уровень 3 легко превращается в имитацию. Если это есть, появляется шанс на уровень 4 — тренажёр функции. ### **Главный тезис** **Образовательный эффект появляется не тогда, когда студент получил хороший продукт, а когда изменился способ его действия.** ### **Пример** «Если студент просто попросил ИИ написать исследовательский вопрос — это слабый уровень 3\. Если он формулирует вопрос, получает критику, сравнивает версии, объясняет, почему отказался от слабой формулировки, и показывает эволюцию вопроса — это уже движение к уровню 4». ### **Важная связь с добросовестностью** Здесь впервые можно коротко связать с будущим блоком про следы: **Следы нужны не для контроля ради контроля, а чтобы видеть формирование функции.** Не разворачивать пока полностью. Это придёт в канвасе. --- --- # **Слайд 18\. Уровень 5: архитектура курса, лаборатории или проектной среды** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать, что сильный эксперимент меняет среду, роли и инфраструктуру. **Заголовок:** **Уровень 5: архитектура среды, а не отдельное задание** ## **Текст для выступления \+ комментарии для сборки** ### На пятом уровне мы перестаём говорить об одном инструменте. Здесь уже проектируется среда действия. Это важный переход. Пока мы обсуждаем тьютора, критика, ассистента или сборщика следов как отдельный инструмент, мы можем удерживать проект в небольшом масштабе. Но если мы начинаем спрашивать, как связаны студент, преподаватель, ИИ-персона, материалы курса, аналитика, оценивание, лаборатория, методист, инженер, данные, следы, тогда мы входим в уровень 5\. Уровень 5 — это архитектура курса, лаборатории или проектной среды. Здесь важно не только что делает ИИ, но и кто вокруг него действует. Какие роли остаются у преподавателя? Какие переходят к ИИ? Что делает студент? Где нужен методист? Где нужен инженер? Кто отвечает за материалы? Кто смотрит логи? Кто интерпретирует следы? Где формируется образовательный результат? Где риск подмены? Где нужно ТЗ? Например, ИИ-персона курса на уровне 5 — это не просто кастомный бот. Это элемент архитектуры курса. У неё есть корпус материалов, позиция, сценарии взаимодействия, границы поведения, связь с заданиями, способ фиксации следов, роль преподавателя в интерпретации этих следов, критерии качества. И, возможно, инженерный контур: база, RAG, логирование, интерфейс. Проектная студия на уровне 5 — это не просто «студенты используют ИИ в проекте». Это распределённая среда: команда, преподаватель, заказчик, симулятор заказчика, критик требований, генератор альтернатив, проверка ограничений, документатор решений, лог изменений, финальное предъявление. Здесь ИИ встроен в проектный цикл, а не добавлен сбоку. Исследовательская лаборатория на уровне 5 — это не просто «ИИ помогает искать литературу». Это среда работы с вопросами, источниками, гипотезами, данными, методами, интерпретациями, публикационными формами. В ней могут быть разные AI-роли: навигатор по корпусу, критик гипотезы, проверяющий операционализации, редактор отчёта, сборщик исследовательских следов. На этом уровне нельзя отделаться промптом. Промпт остаётся важным, но его недостаточно. Нужны материалы, сценарии, роли, данные, следы, интерфейс, правила, ответственность. И именно здесь становится понятно, почему лаборатория нужна не как «те, кто сделают ботика», а как инженерно-методический контур. Если преподаватель сам может сделать прототип — отлично. Но если речь о среде, нужны другие роли. Главный риск уровня 5 — собрать набор ботов вместо архитектуры. Поставить тьютора, критика, справочник, генератор, оценщика — и думать, что это среда. Нет. Среда начинается там, где понятно, как эти роли связаны с деятельностью, где проходят границы ответственности, какие следы собираются, как преподаватель меняет свою функцию, как студент проходит действие, как результат проверяется. Здесь снова виден опыт ТюмГУ с ИИ-персонами. Сам по себе ход с ИИ-персонами радикален не потому, что вместо преподавателя появляется бот. Он радикален, когда меняется функциональное распределение: преподаватель перестаёт быть только источником экспертизы и становится организатором деятельности, настройщиком межличностного опыта, хранителем мотивации; ИИ-персона берёт на себя часть экспертной и картографической функции; методисты и инженеры собирают педагогические технологии и объекты разработки. Вот это уже уровень 5: не инструмент, а перераспределение функций. Поэтому вопрос к участникам: ваш проект остаётся отдельным инструментом или уже требует архитектуры среды? Какие роли должны быть описаны? Какие связи между ними? Что невозможно удержать одним преподавателем? Где нужна лаборатория? Где появляется новая функция курса? ### **Пример ТюмГУ** «Модель ИИ-персон ТюмГУ уже лежит близко к этому уровню: там есть ИИ-персона, медиатор, преподаватель, методисты, разработчики, материалы курса, сценарии и перераспределение функций. То есть это не “один бот”, а новая функциональная сборка курса». ### **Связь со следующим слайдом** Слайд 18 показывает архитектуру среды внутри курса/лаборатории. Слайд 19 показывает, что такой малый эксперимент может быть элементом большой университетской архитектуры. --- --- # **Слайд 19\. Малый эксперимент как элемент большой архитектуры** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** центральный переход между локальным и университетским масштабом. **Заголовок:** **Малый эксперимент как элемент большой архитектуры** **Главная формула:** **Преподаватель не строит весь университет. Но его эксперимент может быть пробным элементом большой модели.** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь нужно соединить то, с чего мы начали, со шкалой масштаба. Малый эксперимент не обязан быть маленьким по смыслу. Он может быть маленьким по реализации, но большим по тому, какую архитектуру проверяет. Это важный способ не перегружать участников. Мы не говорим: «сделайте сразу платформу», «соберите исследовательский пайплайн», «перестройте курс целиком», «измените модель университета». Нет. Мы говорим: сделайте малый эксперимент так, чтобы было понятно, элементом какой большой архитектуры он может быть. Например, один локальный ИИ-критик эссе может быть элементом большой модели добросовестности и оценки. Один курс с ИИ-персоной может быть элементом экосистемы ИИ-персон. Один исследовательский ассистент в семинаре может быть элементом research pipeline. Один проектный симулятор может быть элементом project studio. Один сборщик следов может быть элементом будущей базы экспериментов и аналитического контура. Это даёт участнику правильный масштаб ответственности. Он не обязан построить всё. Но он должен понимать, что именно его эксперимент проверяет. Если он проверяет только локальную пользу, хорошо. Если он проверяет элемент большой модели, надо описать это честно. Здесь важно избежать двух ошибок. Первая — всё измельчить. Тогда все проекты станут набором маленьких улучшений: тут бот, там подсказка, здесь генератор, там ассистент. Через год это трудно собрать в стратегию. Вторая ошибка — всё раздуть. Тогда каждый маленький бот объявят прототипом нового университета, и мы получим инфляцию смысла. Нужен средний ход: малый эксперимент как локальная проверка конкретного элемента большой модели. Допустим, преподаватель делает ИИ-персону курса. Как локальный эксперимент он проверяет, помогает ли персона студенту лучше входить в предмет. Как элемент большой архитектуры он может проверять: можно ли создавать много таких персон, как их описывать, как проверять качество, какие материалы нужны, какие роли остаются за преподавателем, как это входит в платформу. Или исследовательский ассистент. Локально — помогает студентам на НИС. Архитектурно — проверяет, можно ли собрать стандартный контур работы с литературой, вопросами, гипотезами, источниками, следами, отчётами. Или оценочный сценарий. Локально — помогает проверять работы. Архитектурно — проверяет, как в эпоху LLM переустроить доказательство вклада: что студент делал сам, что делегировал, что проверил, как изменил свою позицию. Поэтому на этом слайде нужно показать соответствия. Не как жёсткую классификацию, а как карту возможных связей. Малый эксперимент: ИИ-персона курса → большая архитектура: course-persona ecosystem. Малый эксперимент: research assistant → research pipeline. Малый эксперимент: project simulator → project studio. Малый эксперимент: trace collector → governance/assessment model. Малый эксперимент: bot over materials → campus AI platform или course service. Это также готовит к портфелю. Если каждый проект описан как элемент большой архитектуры, мы можем потом видеть поле: сколько у нас ИИ-персон, сколько research pipeline, сколько governance, сколько проектных студий, где повторяются решения, где нужна общая инфраструктура. Без этого каждый эксперимент остаётся островом. Главный тезис: преподаватель не строит весь университет. Но его эксперимент может быть пробным элементом большой модели. И если мы это понимаем, малый эксперимент перестаёт быть случайной пробой и становится материалом R\&D. ### **Главный тезис** **Преподаватель не строит весь университет. Но его эксперимент может быть пробным элементом большой модели.** ### **Связь со следующими частями** После этого слайда можно говорить о шестом уровне — университете как поле оркестрации интеллектов. А затем о риске снижения планки: заявили большую модель, сделали маленький сервис. --- --- # **Слайд 20\. Уровень 6: университет как поле оркестрации интеллектов** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** не просто сказать «среда», а показать механизм: университет как сеть человеческих и машинных ролей. **Заголовок:** **Уровень 6: университет как поле оркестрации интеллектов** **Главная формула:** **Уровень 6 — не задание для одного преподавателя. Это горизонт, который объясняет, зачем университету нужны малые эксперименты.** --- ## **Текст для выступления \+ комментарии для сборки** ### Шестой уровень — самый большой и самый опасный. Опасный не потому, что он не нужен, а потому что здесь легче всего начать говорить красиво и пусто. «Университет будущего», «гибридный интеллект», «новая образовательная экосистема», «синергия человеческого и искусственного интеллекта» — всё это можно сказать так, что в аудитории станет немного торжественно и совсем непонятно, что делать в понедельник. Поэтому уровень 6 надо объяснять не как футурологию, а как горизонт, который помогает читать малые эксперименты. Университет как поле оркестрации интеллектов — это не один инструмент и не один проект. Это ситуация, где образовательные, исследовательские, проектные и управленческие контуры начинают работать с разными типами человеческих и машинных ролей. В образовательном контуре появляются ИИ-персоны, тьюторы, критики, тренажёры функций, аналитика следов, новые формы оценки. В исследовательском контуре — ассистенты по литературе, критики гипотез, пайплайны данных, domain models, AI-for-Science, поддержка аспирантов и научных групп. В проектном контуре — симуляторы заказчиков, генераторы альтернатив, проверка ограничений, проектные студии. В институциональном контуре — governance, платформы, политики доступа, портфель экспериментов, лаборатория, R\&D-семинары, форум. Уровень 6 возникает не тогда, когда университет закупил доступ к модели. Закупка — это ещё не оркестрация. Можно дать всем ChatGPT и получить просто массовую индивидуальную продуктивность, часть которой будет полезной, часть — имитационной, часть — вообще невидимой. Оркестрация начинается там, где университет понимает роли, границы, следы, сценарии, инфраструктуру, обучение, ответственность и портфель. Здесь снова важен опыт ТюмГУ. Если есть десятки экспериментов и ИИ-персон, это ещё не автоматически уровень 6\. Но это материал, из которого уровень 6 может начать собираться. Если эксперименты описаны, сопоставлены, распределены по паттернам, связаны с R\&D, поддержаны лабораторией, обсуждаются на семинарах, выносятся на форум, тогда появляется университетское поле. Не потому что кто-то написал стратегию, а потому что есть живая карта изменений. На этом уровне меняется вопрос о преподавателе. Преподаватель перестаёт быть единственным носителем экспертизы в аудитории. Но это не значит, что он исчезает. Наоборот, его функция усложняется. Он становится организатором деятельности, настройщиком опыта, хранителем мотивации, проектировщиком ролей, интерпретатором следов, участником распределённой архитектуры. Это не понижение. Это изменение места. Студент тоже меняется. Он уже не просто получает знание и выполняет задания. Он учится действовать в человеко-машинной сети: понимать, что делегировать, что удерживать самому, как проверять машину, как строить связку с ИИ, как доказывать вклад, как не терять собственное мышление в гладком результате. Университет на этом уровне становится инфраструктурой формирования таких связок. Он учит не просто предметам, а нормам гибридной деятельности: исследовательской, инженерной, проектной, предпринимательской, гуманитарной. И вот это уже большая модель. Но она не строится с лозунга. Она строится из малых экспериментов, которые правильно описаны, проверены, сопоставлены и связаны. Поэтому шестой уровень нужен не для того, чтобы все туда немедленно перешли. Он нужен как горизонт. Он объясняет, зачем мы вообще собираем карту экспериментов. Почему важно различать роли. Почему нужны следы. Почему нужен портфель. Почему маленький проект не должен быть слепым. Главный тезис: уровень 6 — это не отдельный инструмент и не один проект. Это горизонт, который объясняет, зачем университету нужны малые эксперименты. ### **Связь со следующим слайдом** После высшего горизонта нужно сразу ввести предохранитель: риск снижения планки. Иначе участники могут вдохновиться красивой рамкой, но в реальности сделать генератор заданий и назвать это новой университетской средой. ### **Важная финальная фраза** **Высокая рамка нужна не для пафоса, а для честного различения: что именно проверяет мой малый эксперимент и какую большую модель он может усилить.** --- # **Слайд 21\. Риск снижения планки** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** сделать практическую проверку радикальных заявок. **Заголовок:** **Риск снижения планки** **Главная формула:** **Главный риск — не ошибка модели, а организационное и онтологическое снижение планки.** --- ## **Текст для выступления \+ комментарии для сборки** ### После уровня 6 нужно сразу поставить тормоз. Не вдохновляющий, а санитарный. Чем выше рамка, тем выше риск деградации. Мы можем заявить большой масштаб, а реализовать маленькую функцию. И это будет хуже, чем честный маленький эксперимент, потому что появится разрыв между словами и делом. Самый частый риск — снижение планки. Заявили изменение деятельности, сделали генератор заданий. Заявили research pipeline, сделали чат для пересказа литературы. Заявили ИИ-персону, сделали справочник. Заявили добросовестность, сделали галочку «использовал ИИ». Заявили платформу, сделали набор разрозненных ботов. Заявили проектную студию, сделали симуляцию заказчика без требований, ограничений и реальной проверки. Это не техническая ошибка. Это организационное и онтологическое снижение. Проект как будто остаётся тем же по названию, но теряет внутреннюю структуру. Слово остаётся, функция исчезает. Например, ИИ-персона. В сильной версии у неё есть позиция, корпус, сценарий, ограничения, тип вопросов, связь с курсом, следы, роль преподавателя. В слабой версии она просто отвечает на вопросы в стиле «я философ». Это может быть мило, но это не персона курса. Это театральный справочник с лёгким запахом гуманитарного кружка. Research pipeline. В сильной версии есть вопрос, корпус, источники, гипотезы, критика, операционализация, лог отказов, проверка метода. В слабой версии — «сделай обзор литературы». Это не pipeline. Это ускоренная фабрика вторичного текста. Добросовестность. В сильной версии мы видим вклад, процесс, версии, делегирование, проверку, человеческое присвоение результата. В слабой — «укажите, пользовались ли ИИ». Это не новая архитектура честности. Это бумажный зонтик под ливнем. Снижение планки опасно ещё и потому, что оно часто выглядит как прагматизм. «Ну давайте начнём проще». Начать проще можно. Но нельзя при этом сохранять высокий ярлык. Если мы начинаем со справочника, называем его справочником. Если начинаем с генератора материалов, называем его генератором материалов. Если начинаем с пилота тьютора, называем его пилотом тьютора. Тогда проект честен и может расти. Если же мы маленькую функцию заворачиваем в большие слова, рост почти невозможен: все делают вид, что уже всё произошло. Поэтому после шкалы масштаба нам нужен слайд про риск деградации. Не чтобы демотивировать, а чтобы защитить проекты. Сильный проект не тот, который сразу самый большой. Сильный проект тот, который удерживает соответствие между заявкой, архитектурой, следами и реализацией. Главный вопрос: во что ваш проект может деградировать? Это не пессимизм. Это инженерная честность. Если вы заранее видите слабую версию, вы можете поставить защиту. Если ИИ-персона может стать справочником, надо удержать позицию и сценарий. Если тьютор может стать решателем задач, надо запретить прямую выдачу ответа и ввести цикл вопросов. Если research assistant может стать пересказчиком, надо ввести источники, гипотезы и проверку. Если оценивание может стать контролем, надо вернуть следы действия и критерии. Итак, главный риск — не ошибка модели. Главный риск — снижение планки проекта. ### **Главный тезис** **Главный риск — не ошибка модели, а организационное и онтологическое снижение планки.** ### **Пример для пояснения** «Если преподаватель говорит: “я хочу ИИ-персону философа”, слабая версия — бот, который отвечает справками из учебника. Сильная версия — персона с позицией, корпусом текстов, режимом спора, критериями интерпретации, следами диалога и ролью в образовательном сценарии. Название одно — “ИИ-персона”, но онтологически это разные проекты». ### **Что должно быть жёстко** Не надо успокаивать аудиторию словами «ничего страшного, можно начать с малого». Начать с малого можно. Но слайд о другом: **малое должно быть честно названо малым**, а не спрятано под большой вывеской. ### **Связь со следующим слайдом** Следующее задание — поставить планку масштаба и сразу указать риск деградации. То есть слайд 21 не просто предупреждение; он вводит рабочий критерий для задания 2\. --- --- # **Слайд 22\. Задание 2: поставить планку масштаба** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** второе задание. Теперь участники уже знают стек ИИ и уровни масштаба. **Заголовок:** **Задание 2\. На какой планке находится ваш эксперимент?** **Инструкция:** 1. Текущий уровень эксперимента: 1–6. 2. Что реально меняется? 3. Какая более сильная версия возможна? 4. Где проект может деградировать? 5. Что надо удержать, чтобы планка не упала? 6. Какая новая переменная или след нужны при подъёме уровня? **Результат:** Участник различает текущую, усиленную и деградированную версии проекта. --- ## **Текст для выступления \+ комментарии для сборки** ### **Текст для произнесения** Теперь второе задание. Первое было про тип ИИ: какая машинная функция фактически нужна вашему эксперименту. Второе — про масштаб: на какой планке находится ваш проект и куда его можно поднять без вранья. Здесь важно не стремиться поставить себе максимальный уровень. Это не конкурс. Если все напишут «уровень 5» или «уровень 6», мы не получим сильную карту. Мы получим инфляцию. Нам нужна честная диагностика. Возьмите свою идею и ответьте на несколько вопросов. Первый: какой текущий уровень? Оптимизация операции? Поддержка преподавателя? Средство действия студента? Тренажёр функции? Архитектура курса? Элемент университетской среды? Второй: что реально меняется? Скорость подготовки? Труд преподавателя? Действие студента? Формируемая функция? Архитектура курса? Институциональная модель? Третий: какая усиленная версия возможна? Например, бот-справочник можно усилить до тьютора. Тьютора — до тренажёра функции. ИИ-персону — до элемента экосистемы. Оценочный сценарий — до модели добросовестности. Генератор проектных идей — до project studio. Четвёртый: во что проект может деградировать? Это обязательный вопрос. Если вы не видите слабую версию своего проекта, значит, вы пока плохо понимаете проект. Любой проект может деградировать. Тьютор — в решатель. Критик — в переписчика. Персона — в справочник. Research assistant — в пересказчика. Аналитика — в дашборд ради дашборда. Governance — в запрет или галочку. Пятый: что нужно удержать, чтобы деградации не случилось? Сценарий, роль ИИ, следы, данные, ТЗ, инфраструктуру, участие преподавателя, критерии, границы помощи, human-in-the-loop. И шестой: какие новые следы или переменные нужны, чтобы подняться на уровень выше? Если вы хотите с уровня 2 перейти на уровень 4, где будет видно формирование функции? Если с уровня 3 на уровень 5, какие роли и инфраструктура нужны? Если с уровня 5 на уровень 6, как проект входит в портфель? Это задание должно дать короткую, но важную формулу: «мой эксперимент сейчас на уровне X, усиленная версия — Y, риск снижения — Z». Например: «Сейчас мой проект на уровне 3: студент использует ИИ для анализа источников. Усиленная версия — уровень 4: тренажёр исследовательского вопроса с фиксацией версий и критикой гипотезы. Риск снижения — пересказ литературы без исследовательской позиции». Вот такая формула уже пригодна для семинара. С ней можно работать. Её можно критиковать. Её можно уточнять. Её можно переводить в ТЗ. А формулировка «ИИ поможет студентам лучше проводить исследование» пока никуда не годится. Она звучит прилично, но в ней нет архитектуры. Итак, задача: поставить планку масштаба. Не завысить. Не занизить. А честно определить текущий уровень, возможное усиление и риск деградации. ### **Время** 10 минут индивидуально. 5 минут — короткий сбор в чат/доску: каждый пишет одну строку: **“Мой эксперимент: уровень X, усиленная версия Y, риск снижения Z.”** ### **Как использовать результаты дальше** Эти ответы станут материалом для семинаров. На исследовательских семинарах можно будет быстро видеть, где у проекта конфликт между заявленной амбицией и фактическим уровнем. --- --- # **Слайд 23\. Как читать кейсы: не витрина, а карта паттернов** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** не дать кейсам превратиться в обзор «кто что сделал». **Заголовок:** **Кейсы читаются не как витрина, а как карта паттернов** **Главная формула:** **Мы не копируем университеты. Мы извлекаем архитектурные паттерны.** ## **Текст для выступления \+ комментарии для сборки** ### Теперь мы можем перейти к кейсам. И здесь опять нужна защита от неправильной рамки. Кейсы нельзя читать как витрину. Нельзя просто смотреть: вот университет такой-то запустил платформу, вот другой дал доступ к ChatGPT Edu, вот третий сделал песочницу, вот четвёртый встроил ИИ в LMS. Если читать так, получится туризм по инновациям. Съездили глазами, привезли магнитик, повесили на холодильник стратегии. Кейсы нам нужны не для восхищения и не для копирования. Они нужны как карта паттернов. Мы смотрим не на то, кто что красиво назвал, а на архитектуру: какие роли различены, где находится ИИ, что меняется в образовательном цикле, есть ли следы, есть ли governance, кто отвечает, как масштабируется, какие метрики есть, где риск имитации. Например, campus AI platform. Витринное чтение: университет дал всем доступ к ИИ. Архитектурное чтение: появилась единая точка доступа, правила использования, контроль данных, роли пользователей, возможно конструктор ботов, поддержка преподавателей, сбор кейсов, инфраструктурный слой. Self-service builder. Витринное чтение: преподаватели могут создавать ботов. Архитектурное чтение: преподаватель становится автором AI-роли; университет задаёт среду, где эти роли создаются, ограничиваются, подключаются к материалам, разворачиваются для студентов. Sandbox. Витринное чтение: есть песочница, можно пробовать. Архитектурное чтение: университет создаёт безопасную зону для проверки сценариев, рисков, данных, политик и педагогических эффектов до масштабирования. Course persona. Витринное чтение: бот в образе автора или эксперта. Архитектурное чтение: реконструируется позиция, корпус, сценарий, педагогическая функция, следы взаимодействия, место преподавателя. И так далее. То есть мы каждый раз читаем кейс не как «что они сделали», а как «какую архитектурную форму они проверяют». Это особенно важно для ТюмГУ. У нас нет задачи копировать ASU, Oxford, Harvard, Columbia, UCI или кого-то ещё. У каждого университета свои ресурсы, политика, рынок, инфраструктура, правовые ограничения, культура преподавания. Копирование чужого кейса без архитектурного перевода — это быстрый способ получить дорогую имитацию. Мы должны извлекать паттерны и задавать вопрос: какой элемент этого паттерна релевантен нашим экспериментам? Внешние кейсы помогают увидеть, что происходит в мире: управляемые платформы, кампусные лицензии, песочницы, конструкторы AI-ролей, LMS-агенты, governance, learning mode, research assistants. Но нам нужно не «сделать как у них», а понять, какие формы уже повторяются и как они помогают описать наши проекты. Поэтому дальше мы будем читать кейсы через несколько паттернов: governed campus platform, self-service builder, sandbox/playground, course persona/tutor, project studio/research pipeline, governance/assessment. Это не исчерпывающая классификация. Это рабочая карта. Она нужна, чтобы участник мог сказать: мой проект похож на такой паттерн, но в маленьком масштабе; или мой проект соединяет два паттерна; или мой проект пока вообще не попадает в паттерн, и это тоже интересно. Главная формула: кейсы нужны не для подражания, а для координатной сетки. Они позволяют понять, где стоит ваш эксперимент и какие сильные формы уже есть в мире. --- --- # **Слайд 24\. Паттерн 1: governed campus platform** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** первый архитектурный паттерн — управляемая кампусная ИИ-среда. **Заголовок:** **Governed campus platform** **Кейсы:** ASU CreateAI; UCI ZotGPT; Columbia CU-GPT; Oxford ChatGPT Edu; University of Washington Purple AI. **Что это даёт для участников:** Локальный бот может быть не отдельным ботом, а прототипом будущего кампусного сервиса. --- ## **Текст для выступления \+ комментарии для сборки** ### Первый паттерн, который нам нужно разобрать, — governed campus platform. И теперь важно не произнести это как красивое английское название. За ним стоит вполне конкретный архитектурный сдвиг: университет перестаёт делать вид, что ИИ — это частная игрушка студента или преподавателя, и начинает собирать управляемую кампусную среду. Не «каждый сам зашёл в ChatGPT, как смог», а единая точка доступа, правила, роли пользователей, безопасность данных, выбор моделей, иногда конструктор ботов, иногда учёт использования, иногда портфель сценариев. Это не один кейс, а семейство кейсов. ASU CreateAI — сильный пример, потому что там речь не просто о лицензии на внешний чат, а о кампусной GenAI-среде, построенной “by ASU for ASU”. Внутри этой модели есть пользователь — преподаватель, сотрудник, студент; есть создаваемый AI-experience — бот, ассистент, симулятор, продукт под конкретную задачу; и есть институциональная среда управления доступом и данными. CreateAI важен не тем, что «у ASU есть ИИ», а тем, что университет пытается превратить ИИ в управляемую инфраструктуру, внутри которой можно создавать разные функциональные роли. Там уже появляется переход от “общего чата” к множеству AI-опытов, закреплённых в университетской среде. UCI ZotGPT — другой вариант того же паттерна. Это зонтичная кампусная среда: ZotGPT Chat, Creator, ClassChat и связанные сервисы. В ZotGPT важна не только возможность поговорить с моделью, а то, что появляются разные роли: массовый пользователь, преподаватель или сотрудник как автор специализированного бота, AI-ассистенты под разные задачи и инфраструктурный контур безопасности. Там есть логика файлов, истории, большого контекста, работы в инфраструктуре UCI. То есть ИИ перестаёт быть личным инструментом и становится университетским сервисом, где можно разворачивать кастомные роли. Columbia CU-GPT показывает ещё одну грань. Это много-модельный AI-интерфейс внутри кампуса, развёрнутый IT-департаментом. Там важны функции вроде загрузки файлов, хранения истории, мониторинга использования и даже учёта расходов на API. Почему это важно? Потому что кампусная платформа — это не только педагогика. Это ещё стоимость, безопасность, управление, отчётность, доступ, инфраструктура. Если этого нет, университет живёт в режиме «все пользуются, никто не управляет, расходы и данные растворяются где\-то за горизонтом». Oxford ChatGPT Edu — более лицензированный, кампусный вариант. Университет предоставляет доступ студентам и преподавателям на уровне институции, но при этом роли всё равно разделяются: IT-службы управляют доступом, преподаватели определяют условия использования в образовательных ситуациях, студенты и staff используют сервис в рамках правил. Это слабее, чем полноценный builder, но сильнее, чем стихийное использование. Здесь главное — нормализация ИИ как официального кампусного слоя, а не как подпольного инструмента. University of Washington Purple AI — пример университетского чат-ассистента с единой точкой доступа через университетскую учётную запись, доступом к современным LLM и понятной ролью IT как оператора. У него тоже агентность невысокая: это не автономная система, не образовательный агент полного цикла, а функциональный ассистент. Но архитектурно он важен тем, что показывает: кампус начинает собирать ИИ как сервис, а не оставляет его в частных аккаунтах пользователей. И вот из этих кейсов извлекается паттерн. Governed campus platform — это не «купили ChatGPT Edu». Покупка лицензии — только один слабый вариант. Сильная версия начинается там, где есть управляемая среда: кто имеет доступ, какие данные можно использовать, какие модели подключены, какие роли можно создавать, как поддерживаются преподаватели, как фиксируются сценарии, какие ограничения действуют, как собираются кейсы, где IT и администрация выступают оркестратором. Для участников это важно вот почему. Их локальный бот может быть не просто локальным ботом. Он может быть прототипом будущего кампусного сервиса. Если вы делаете ИИ-персону курса, надо спросить: что нужно стандартизировать, чтобы таких персон можно было создавать много? Материалы? Роль? Системные инструкции? Доступ? Логи? Проверку качества? Если вы делаете тьютора, как он должен быть развёрнут для студентов? Если сборщик следов — где хранятся данные? Если research assistant — какие источники он имеет право читать? Если оценочный контур — как он связан с правилами университета? Этот паттерн нужен не для того, чтобы сказать «ТюмГУ должен сделать как ASU». Нет. Это был бы дорогой способ имитировать чужую траекторию. Нам нужно извлечь архитектурную форму: локальные эксперименты могут быть прочитаны как требования к будущей управляемой среде. И если мы не зададим эти требования из экспериментов, платформа потом будет закуплена как общий доступ к модели. А общий доступ к модели — это не образовательная архитектура. Это просто общий кран, из которого все пьют разную воду и потом спорят, кто отравился первым. Главный тезис: governed campus platform превращает разрозненное использование ИИ в управляемую университетскую инфраструктуру. Но только если вокруг неё есть роли, правила, безопасность, поддержка, возможность создавать специализированные AI-роли и связь с портфелем экспериментов. ### **Главный тезис** **Платформа превращает разрозненное использование ИИ в управляемую университетскую инфраструктуру.** ### **Вопрос к аудитории** **Если ваш проект стал бы элементом campus platform, что пришлось бы стандартизировать: материалы, роль, доступ, логи, правила, интерфейс, поддержку?** --- --- # **Слайд 25\. Паттерн 2: self-service builder / AI-role constructor** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать модель, где преподаватель становится автором AI-роли. **Заголовок:** **Self-service builder: преподаватель как автор AI-роли** **Кейсы:** ASU CreateAI Builder; UCI Creator; ZotGPT Creator; частично ТюмГУ ИИ-персоны. **Главная формула:** **Преподаватель не просто использует общий чат, а задаёт новую функциональную роль в образовательной среде.** --- ## **Текст для выступления \+ комментарии для сборки** ### Второй паттерн — self-service builder или AI-role constructor. Он близок к governed campus platform, но акцент другой. В первом паттерне центр тяжести — университетская среда доступа и управления. Во втором — способность преподавателя, сотрудника, методиста или проектной команды создавать специализированную AI-роль. ASU CreateAI Builder здесь снова важен, но теперь мы смотрим на него с другой стороны. Не как на кампусную платформу вообще, а как на self-service среду, где пользователь может загружать материалы, задавать инструкции поведения модели, создавать чатбота или AI-продукт под конкретную задачу и разворачивать его внутри управляемой университетской инфраструктуры. В архитектурном смысле это сдвиг: преподаватель больше не просто открывает общий чат. Он задаёт новую функциональную единицу среды. UCI Creator и ZotGPT Creator дают похожий ход. В UCI есть не только ZotGPT как сервис для общения с моделью, но и слой Creator, где можно создавать кастомных ботов и рабочие процессы. Это означает, что университет признаёт: преподавателю или подразделению нужен не один общий ассистент, а разные роли под разные учебные, административные, исследовательские и сервисные задачи. Для ТюмГУ это особенно важно, потому что линия ИИ-персон фактически находится рядом с этим паттерном. ТюмГУ уже делает не просто «ботов», а ИИ-персон: реконструкции экспертов в предметной области или исторически значимых личностей, кастомизированные чат-боты на базе больших языковых моделей, векторные базы экспертных материалов дисциплины, системные промпты и сценарии, запускаемые по намерениям пользователя. Это не полностью self-service builder в готовом промышленном смысле, но это содержательно тот же поворот: преподаватель и методист начинают проектировать AI-роль внутри образовательного процесса. Вот здесь надо быть очень точными. AI-role constructor — это не фабрика декоративных персонажей. Очень легко сделать массовое производство слабых «персон»: профессор Кант, инженер Петров, тьютор по биологии, ассистент по методологии, и все они фактически отвечают как справочник с разными шляпами. Это не роль. Это театр интерфейса. Роль начинается там, где понятно, какую функцию ИИ выполняет в деятельности. Он объясняет? Спорит? Критикует? Тренирует? Моделирует? Оценивает? Сопровождает? Удерживает позицию автора? Не даёт студенту перепрыгнуть через затруднение? Возвращает к материалу? Фиксирует следы? Поэтому self-service builder важен не потому, что преподаватель может «сам собрать ботика». Это как раз слабая версия. В сильной версии преподаватель становится автором образовательной роли. Он задаёт цель, материалы, границы поведения, сценарии, критерии, стиль взаимодействия, правила использования. Он проектирует не ответ модели, а место ИИ в образовательной ситуации. Для участника это прямой вопрос. Если ваш проект — AI-роль, какая у неё функция? Не название, а функция. «ИИ-персона курса» — это ещё не ответ. Какая персона? Картограф предметной области? Оппонент? Тьютор? Тренажёр функции? Навигатор по материалам? Симулятор собеседника? Критик ошибки? Сборщик следов? И дальше вопрос: что должно быть в конструкторе, чтобы такая роль была воспроизводимой? Какие материалы загружаются? Какие инструкции задаются? Как ограничивается поведение? Как проверяется качество? Как роль разворачивается для курса, сервиса, проекта? Кто отвечает за обновление материалов? Где хранятся логи? Как преподаватель видит, что происходит? Главная формула: преподаватель не просто использует общий чат, а задаёт новую функциональную роль в образовательной среде. Это другой уровень педагогической работы. Не «научиться промптить», а научиться проектировать AI-участника образовательной ситуации. ### **Вопрос к аудитории** **Если ваш проект — AI-роль, какая у неё функция: объяснять, спорить, критиковать, тренировать, моделировать, оценивать, сопровождать?** --- --- # **Слайд 26\. Паттерн 3: sandbox / playground / controlled experimentation** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать модель безопасного экспериментирования без преждевременного масштабирования. **Заголовок:** **Sandbox / playground: управляемое экспериментирование** **Кейсы:** Harvard AI Sandbox; Stanford AI Playground; Berkeley AI Hub; университетские песочницы. **Главная формула:** **Песочница нужна не для осторожности ради осторожности, а чтобы отделить рабочие сценарии от имитации.** --- ## **Текст для выступления \+ комментарии для сборки** ### Третий паттерн — sandbox, playground, controlled experimentation. Его легко понять неправильно. Можно решить, что песочница — это просто место, где можно «поиграться» с моделями. Ну да, дали людям безопасную коробку, чтобы они там что-то пробовали и не ломали университет. Но сильный смысл песочницы не в игре. Песочница нужна, чтобы отделить рабочий сценарий от имитации до того, как мы потащили его в курс, лабораторию, платформу или отчёт. Harvard AI Sandbox — хороший пример: это secure generative AI environment для университетского сообщества, доступ к нескольким LLM через единый интерфейс, с акцентом на приватность и безопасность. Важна не только возможность работать с моделями, а то, что университет специально создаёт огороженную среду: данные не должны уходить в обучение моделей поставщиков, есть правила, есть интерфейс, есть возможность экспериментировать с задачами, документами, продуктивностью. Это не педагогическая революция сама по себе. Но это инфраструктурная зона, где можно тестировать сценарии без немедленного включения в массовый процесс. Stanford AI Playground — похожий, но по-своему интересный кейс. В корпусе он описан как безопасный доступ к разным AI-моделям для большинства людей в Stanford; ценен ещё и тем, что по нему есть публичные метрики масштаба: тысячи пользователей, миллионы сообщений, десятки миллиардов токенов. Это показывает, что playground может быть не маленькой лабораторной игрушкой, а массовым кампусным сервисом контролируемого доступа. Но опять же: образовательные метрики не равны метрикам использования. Миллион сообщений — это ещё не миллион случаев обучения. Это важное различение. Berkeley AI Hub / Campus AI Sandbox — ещё один вариант того же инфраструктурного хода: multi-model interface, безопасная среда, campus gateway. В таких кейсах университет не столько говорит «вот новая педагогика», сколько создаёт управляемую зону, где можно проверять модели, данные, сценарии, ограничения, риски и потенциальные учебные применения. Для ТюмГУ этот паттерн особенно полезен. Потому что участники сейчас не должны сразу масштабировать свои эксперименты. Им нужно проверить: что делает ИИ, где он ошибается, как реагируют студенты, какие данные можно использовать, какие следы остаются, какие правила нужны, что надо запретить, где нужна лаборатория, где достаточно методической настройки. Песочница — это не осторожность ради осторожности. Это способ не перепутать рабочий эксперимент с эффектной демонстрацией. Например, преподаватель хочет сделать ИИ-персону курса. Песочница нужна, чтобы проверить: персона держит позицию или уходит в общий пересказ? Не придумывает ли источники? Не даёт ли готовые ответы там, где должна задавать вопросы? Может ли студент обойти сценарий? Какие следы нужны преподавателю? Какой материал должен быть в базе? Какие намерения пользователя надо распознавать? Или проектный симулятор. До запуска в реальном курсе надо понять: симулятор заказчика создаёт настоящие ограничения или просто вежливо играет в бизнес? Проверяет ли требования? Умеет ли сопротивляться команде? Не превращается ли в генератор красивых идей без ответственности? Или research assistant. Песочница должна показать: это навигатор исследования или фабрика пересказа литературы? Есть ли проверка источников? Есть ли фиксация гипотез? Есть ли следы отказа от слабых вариантов? Главная формула: песочница нужна не для осторожности ради осторожности, а чтобы отделить рабочие сценарии от имитации. В нашем контексте это означает: не каждый эксперимент сразу должен стать инфраструктурой. Некоторые должны пройти через песочницу, семинарную критику и проверку слабых мест. ### **Вопрос к аудитории** **Что в вашем эксперименте нужно сначала проверить в песочнице, прежде чем просить лабораторию о реализации?** --- --- # **Слайд 27\. Паттерн 4: course persona / tutor / Socratic mode** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать педагогически заданные ИИ-роли. **Заголовок:** **Course persona / tutor / Socratic mode** **Кейсы:** ТюмГУ ИИ-персоны; Tutor CoPilot; Dartmouth TeamChat; Claude learning mode; AI Conversation. **Главная формула:** **ИИ-персона — не справочник, а педагогически заданный участник образовательной ситуации.** --- ## **Текст для выступления \+ комментарии для сборки** ### Четвёртый паттерн — course persona, tutor, Socratic mode. Это самый близкий к текущей тюмГУшной линии паттерн, но именно поэтому его надо разобрать особенно аккуратно. Потому что здесь легко скатиться в красивую, но слабую форму: «мы сделали персонажа», «студент с ним поговорил», «всем понравилось». А нам нужна не декоративная персонализация, а педагогически заданная ИИ-роль. ТюмГУ ИИ-персоны — центральный локальный кейс. В исходной логике это не просто чатботы. Содержательно — реконструкция экспертов в предметной области или исторически значимых личностей. Технически — кастомизированный чат-бот на базе больших языковых моделей, с векторной базой материалов дисциплины, системными промптами и сценариями, запускаемыми при распознавании намерений пользователя. Архитектурно — это попытка перераспределить функции: экспертность и картографирование предметной области частично выносятся в ИИ-персону, а преподаватель смещается к организации деятельности, настройке межличностного опыта и удержанию мотивации. Tutor CoPilot показывает другую линию: не персона как исторический или экспертный голос, а адаптивный тьютор, который анализирует понимание студента и генерирует дополнительные упражнения или объяснения там, где студент ошибается. В корпусе это уже ближе к агентности 3/6: не просто ответчик, а частично автономный контур адаптивного обучения внутри курса. Но важно: ценность Tutor CoPilot не в том, что он «умный чат», а в том, что он встроен в цикл диагностики и дополнительного учебного действия. Dartmouth Greenhouse TeamChat — ещё один вариант: внутренний LLM-сервис, ориентированный на обучение, где преподаватели задают инструкции, студенты взаимодействуют с чатом для учебных задач, IT регламентирует доступ и логирует взаимодействие. Здесь агентность ниже, но важен сам паттерн: AI не просто внешний чат, а учебно ориентированная внутренняя роль с инструкциями и контуром доступа. Claude learning mode и AI Conversation / Blackboard AI Conversation важны как pedagogy-shaped dialogue. Это не автономная система обучения, а форма диалога, специально ограниченная педагогикой: не сразу выдавать ответ, задавать вопросы, поддерживать рефлексию, работать как учебный собеседник или graded activity. В таких решениях главный ход — не мощность модели, а форма диалога. Из этих кейсов следует общий паттерн: ИИ имеет роль внутри курса; связан с материалами или заданной ситуацией; работает по сценарию; не просто даёт ответ, а ведёт диалог; может удерживать позицию, критику, вопрос, тренировку, рефлексию. ИИ-персона — не справочник, а педагогически заданный участник образовательной ситуации. Это различение надо повторить. Справочник отвечает. Тьютор ведёт. Персона удерживает позицию. Критик сопротивляется. Сократический режим не даёт студенту спрятаться в готовый ответ. Если всё это превращается в «задай вопрос — получи объяснение», паттерн деградировал. Например, ИИ-персона Канта. Слабая версия — пересказ Канта человеческим языком. Средняя версия — ответы от лица Канта. Сильная версия — собеседник, который удерживает кантовскую систему различений, ловит психологизацию трансцендентального, возвращает к условиям возможности опыта, не даёт студенту заменить философский ход бытовым объяснением. Вот это уже педагогическая роль. Вопрос участнику: если ваш проект содержит персону, тьютора или AI-собеседника, что он должен делать кроме ответа? Где он удерживает вопрос? Где критикует? Где тренирует функцию? Где оставляет следы? Где преподаватель видит, что произошло? Где студент не может просто получить готовую поверхность? Главная формула: ИИ-персона — не справочник, а педагогически заданный участник образовательной ситуации. ### **Главный тезис** **ИИ-персона — не справочник, а участник образовательной ситуации с заданной функцией.** ### **Вопрос к аудитории** **Если в вашем эксперименте есть ИИ-персона или тьютор, что она обязана делать, кроме ответа на вопросы?** --- # **Слайд 28\. Паттерн 5: project studio / research pipeline** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать, что ИИ-эксперимент может лежать в исследовании, разработке, проектировании. **Заголовок:** **Project studio / research pipeline** **Кейсы:** MIT; KAIST; Tsinghua; AI-for-Science; AI Scientist; Kosmos; мультиагентная аспирантура. **Содержание:** Контур: проблема → гипотеза → данные → анализ → прототип → проверка → интерпретация → отчёт / статья / продукт. **Главная формула:** **Если образование включает исследование и разработку, то AI-for-Science и проектные студии — часть образовательной трансформации.** --- ## **Текст для выступления \+ комментарии для сборки** ### Пятый паттерн — project studio / research pipeline. Здесь важно сразу не смешать две формы. Project studio и research pipeline близки, но не одно и то же. Project studio ориентирована на проектирование, разработку, прототип, требования, ограничения, заказчика, продуктовую проверку. Там ИИ может помогать генерировать альтернативы, критиковать требования, симулировать пользователя или заказчика, проверять ограничения, поддерживать прототипирование, документировать решения. Research pipeline ориентирован на исследовательский вопрос, литературу, гипотезу, данные, метод, анализ, интерпретацию, статью или отчёт. Там ИИ может быть навигатором по литературе, критиком гипотезы, помощником операционализации, аналитиком данных, проверяющим метода, оппонентом интерпретации, редактором научного текста, сборщиком исследовательских следов. Общий принцип один: ИИ встраивается не как «помощник написать текст», а как участник цикла работы с неопределённостью. KAIST даёт понятный пример проектно-инженерного варианта. В корпусе он описан как интеграция LLM в проектные инженерные курсы, где AI помогает формировать технические спецификации и проводить предварительную проверку решений. Роли разделены: преподаватель задаёт архитектуру проекта, AI выполняет аналитическую и генеративную поддержку, студенты взаимодействуют с ним как с ассистентом-аналитиком. Это ещё не автономная агентная сеть, но это уже не просто «бот для текста»: ИИ входит в проектный цикл, помогает думать о спецификациях и ограничениях. Tsinghua показывает другой вариант: LLM-поддержка в инженерных и управленческих программах, курсы по AI-системному проектированию, генерация дополнительных кейсов и сценариев, симуляция решений, а в отдельных лабораториях — multi-agent сценарии для инженерных симуляций. В образовательном процессе они остаются инструментальными, но сам паттерн важен: AI становится частью инженерной и управленческой подготовки через сценарии, симуляции, проектную работу. MIT в этой группе можно использовать как маркер исследовательско-проектной среды, где AI связывается с разработкой, лабораторией, прототипированием и работой с неопределённостью, а не только с учебным заданием. Но важнее не бренд MIT, а тип: студент учится не только отвечать на вопросы курса, а работать в среде исследования и разработки, где ИИ помогает расширять пространство вариантов, проверять ограничения и ускорять движение от проблемы к прототипу. AI-for-Science и AI Scientist выводят нас ещё дальше. В первой установке уже был пример AI Scientist-v2: система провела расчёты и эксперименты, сгенерировала гипотезу, проанализировала литературу и написала статью, принятую на ICLR. Это не «чат помог студенту написать текст». Это машина, которая входит в исследовательский цикл. Конечно, это не означает, что надо завтра заменить аспиранта системой. Это означает, что образовательная подготовка исследователя должна учитывать новый контур: гипотезы, литература, код, анализ данных, отчёт могут быть частично машинно поддержаны. Kosmos / Edison ещё нагляднее показывает research pipeline. В типичном запуске пользователь загружает научный набор данных; система анализирует около 1500 релевантных академических статей, параллельно создаёт и выполняет десятки тысяч строк кода, формирует отчёт с выводами и план дальнейшего анализа. По оценке, один запуск из серии циклов может соответствовать значительному объёму PhD-уровня работы, но качество не равномерное: утверждения по данным и литературе подтверждаются заметно чаще, а синтез новых гипотез слабее. Это очень важное место: research pipeline ускоряет работу, но не отменяет человеческую интерпретацию и проверку. Мультиагентная аспирантура — наша более радикальная рамка. Там аспирант строит не просто диссертацию, а сеть агентов: поиск гипотез, отбор литературы, планирование эксперимента, интерпретация результатов, лог проекта, артефакт в виде статьи, диссертации или продукта. Это уже образовательная программа как обучение работе с гибридной исследовательской архитектурой. Для участников вопрос такой: ваш эксперимент лежит только в учебном задании или может быть встроен в исследовательский или проектный цикл? Если студент делает проект, где ИИ просто помогает написать презентацию, это слабая версия. Если ИИ помогает проверять требования, ограничения, альтернативы, прототип, контакт с заказчиком и основания выбора — это project studio. Если студент просит LLM пересказать литературу — слабая версия. Если он строит вопрос, получает критику гипотезы, фиксирует выбор источников, проверяет метод и оставляет следы отказа от слабых вариантов — это research pipeline. Главная формула: если образование включает исследование и разработку, то AI-for-Science и проектные студии — часть образовательной трансформации. ### **Главный тезис** **Если образование включает исследование и разработку, то ИИ-пайплайны и проектные студии — часть образовательной трансформации.** ### **Вопрос к аудитории** **Ваш эксперимент работает только с учебным продуктом или может быть встроен в исследовательский / проектный цикл?** ### **Связь со следующим слайдом** После project/research паттерна надо сразу перейти к governance/assessment, потому что чем больше мы допускаем ИИ в исследование и разработку, тем важнее становится вопрос: как доказывать вклад, добросовестность и качество действия? --- --- # **Слайд 29\. Паттерн 6: governance / assessment / добросовестность** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать, что оценивание и правила — это не «хвост», а отдельная архитектура. **Заголовок:** **Governance / assessment / добросовестность** **Кейсы:** Notre Dame approved tools; UCL / assessment; AIAS-подходы; Harvard-разведение режимов использования; возврат устных и рукописных проверок как контрход. **Главная формула:** **ИИ меняет не только задания, но и правила доказательства вклада.** --- ## **Текст для выступления \+ комментарии для сборки** ### Шестой паттерн — governance / assessment / добросовестность. Его нельзя ставить в конец как скучный административный хвост. В эпоху LLM оценивание и правила становятся частью архитектуры эксперимента. ИИ меняет не только задания, но и способы доказательства вклада. Notre Dame approved tools — хороший пример governance-подхода: университет формирует список разрешённых AI-инструментов, включая ChatGPT Edu-подобные задачи, задаёт правила типов данных, различает роли faculty/staff и студентов, помещает AI в контур безопасного ассистента. Агентность здесь низкая, но архитектурный смысл важный: ИИ не просто разрешён или запрещён, он каталогизирован, допущен по правилам, связан с классами данных и условиями курса. UCL / assessment-подходы и AIAS-подобные шкалы показывают другой ход: не просто «можно» или «нельзя», а режимы допустимого использования ИИ в заданиях. Где ИИ запрещён, где разрешён для поиска идей, где разрешён для редактирования, где должен быть раскрыт, где является частью задания. Это важно, потому что бинарная рамка «использовал / не использовал» уже почти не работает. Она слишком грубая. Нужно различать тип помощи, степень делегирования, следы, вклад, проверку. Harvard-подобное разведение режимов использования показывает, что один и тот же инструмент в разных заданиях может иметь разный статус. В одном случае ИИ запрещён, потому что задание проверяет базовую функцию. В другом разрешён как объект критики. В третьем — обязателен, потому что студент должен научиться работать с ним. В четвёртом — допустим только при раскрытии. Это и есть governance как архитектура задания, а не табличка «ИИ нельзя». Возврат устных и рукописных проверок — важный контрход. Его не надо высмеивать как реакционную панику. Иногда он нужен. Если продукт перестал доказывать способность, университет возвращается к форматам, где труднее делегировать всё машине: устный экзамен, очная защита, рукописная работа, blue books. Но если это единственный ответ, он бедный. Это защита старой формы, а не новая архитектура. Сильный ответ должен не только запрещать, но и проектировать новые способы доказательства вклада. Вот ключевая проблема. Раньше преподаватель мог относительно спокойно смотреть на эссе, код, отчёт, презентацию как на след деятельности. Теперь продукт может быть гладким без соответствующего действия. Студент может сдать текст, не пройдя аргументацию. Код может работать, но студент не понимает ошибки. Обзор литературы может быть убедительным, но исследовательского вопроса у человека нет. Презентация может выглядеть проектной, но команда не проходила через требования и ограничения. Поэтому добросовестность в ИИ-среде — это не только студент честно сказал, пользовался ли он ChatGPT. Это слишком слабая рамка. Добросовестность становится свойством всего контура: студент показывает вклад, версии, делегирование и проверку; преподаватель проектирует задание так, чтобы была видна функция; администрация определяет допустимые инструменты и классы данных; лаборатория обеспечивает хранение следов, логирование, воспроизводимость и ограничения моделей. Нужно оценивать не только продукт, но и процесс, вклад, следы, ответственность ролей. Что сделал человек? Что сделала машина? Как человек проверил результат? Что изменилось между версиями? Где были ошибки? Что студент понял и присвоил? Где преподаватель видит формирование функции? Где проект не сводится к контролю, а действительно даёт доказательство действия? Главная формула: ИИ меняет не только задания, но и правила доказательства вклада. ### **Главный тезис** **В ИИ-среде оценивать нужно не только продукт, но и вклад, процесс, следы и ответственность ролей.** ### **Вопрос к аудитории** **Какие следы должны появиться в вашем эксперименте, чтобы можно было отличить сформированную способность от сгенерированного продукта?** ### **Связь со следующим слайдом** После внешних паттернов надо показать, что ТюмГУ не в нулевой точке. У него уже есть материал, из которого может собираться портфель. Поэтому следующий слайд — про ТюмГУ как внутреннюю модель. --- --- # **Слайд 30\. ТюмГУ: от множества экспериментов к портфелю изменений** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** ввести понятие портфеля и показать место ТюмГУ. **Заголовок:** **ТюмГУ: от множества экспериментов к портфелю изменений** **Главная формула:** **То, что для преподавателя эксперимент, для университета — элемент портфеля изменений.** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь нужно вернуть внешние кейсы в ТюмГУ. И здесь главный переход: множество экспериментов само по себе ещё не является университетским изменением. Это может быть просто множество экспериментов. Хороших, интересных, ярких, отдельных. Университетское изменение начинается там, где эксперименты становятся портфелем. У ТюмГУ уже есть сильный материал: более 60 экспериментов, более 60 ИИ-персон, более 2000 студентов, Центр образовательных разработок на основе технологий ИИ, межуниверситетские R\&D-семинары, заявка на государственное задание, форум. Это не нулевая точка. Но именно поэтому следующий шаг сложнее. Когда экспериментов мало, можно просто помнить их по именам авторов. Когда их десятки, нужна карта. Иначе начинается университетская археология: кто-то где\-то что-то делал, в какой-то презентации было, кажется, похожее, но никто не помнит, где оно лежит и чем закончилось. Один и тот же эксперимент должен читаться на трёх уровнях. Для преподавателя это локальная проблема курса или деятельности. Например: студенты не читают сложные тексты; не умеют формулировать исследовательский вопрос; не проходят проектный цикл; не различают критерии; теряют мотивацию; списывают через ИИ. Для центра или лаборатории тот же эксперимент — это тип решения, ТЗ, инфраструктурная цена, повторяемость. Что надо реализовать? Нужна ИИ-персона, RAG, логирование, интерфейс, аналитика, сценарий, конструктор ролей? Можно ли это повторить в другом курсе? Какие элементы надо стандартизировать? Что требует инженера, а что преподаватель может сделать сам? Для университета тот же эксперимент — элемент портфеля моделей, радикальных экспериментов, масштабируемых практик и R\&D. Он относится к course persona ecosystem? К research pipeline? К project studio? К governance / assessment? К campus platform? К AI-literacy? К лабораторной инфраструктуре? К новому функциональному распределению преподавателя и ИИ? И вот это трёхуровневое чтение критически важно. То, что для преподавателя эксперимент, для университета — элемент портфеля изменений. Если преподаватель делает ИИ-персону, он решает свою задачу курса. Но центр видит: нужна технология создания персон, критерии качества, база материалов, сценарии, поддержка. Университет видит: формируется экосистема ИИ-персон и новый контур функций преподавателя. Если преподаватель делает оценочный сценарий, он решает проблему проверки работ. Центр видит: нужны следы, логи, правила, форматы раскрытия. Университет видит: это кусок новой модели добросовестности. Без портфеля мы получим набор частных инициатив. С портфелем — появляется возможность видеть повторы, группировать проекты, находить взаимно усиливающие идеи, сравнивать с мировыми кейсами, выделять радикальные эксперименты, формировать R\&D-повестку и инженерный backlog. И это ровно то, о чём уже говорилось в обсуждениях: нужна не просто доска с идеями, а общий ресурс, где инициативы, эксперименты, реализованные и нереализованные, разные по готовности, могут быть размещены в одном пространстве. По сути — морфологический ящик, карта проектов, где каждый эксперимент описан профилем. Главная формула: то, что для преподавателя эксперимент, для университета — элемент портфеля изменений. ### **Главный тезис** **Один эксперимент имеет разные масштабы чтения: локальный, лабораторный, университетский.** ### **Переход** После этого участники должны сделать задание 3: определить, к какому паттерну относится их эксперимент и как он может читаться как элемент портфеля. --- --- # **Слайд 31\. Задание 3\. Какой паттерн стоит за вашим экспериментом?** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** третье задание. Теперь участники соотносят свой эксперимент не с уровнем, а с архитектурным паттерном и портфелем. **Заголовок:** **Задание 3\. Какой паттерн стоит за вашим экспериментом?** **Инструкция:** 1. Мой эксперимент похож на какой паттерн? 2. Какой кейс из базы наиболее близок? 3. Что в моём проекте локально? 4. Что потенциально масштабируется? 5. Что может стать элементом портфеля ТюмГУ? 6. Что нужно описать, чтобы проект был сопоставим с другими? **Результат:** Проект получает координату в корпусе кейсов. --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь третье задание. Первое задание было про тип ИИ: какая машинная функция фактически нужна вашему эксперименту. Второе — про масштаб: на какой планке находится проект, какая усиленная версия возможна и где он может деградировать. Теперь третий вопрос: какой архитектурный паттерн стоит за вашим экспериментом? Это не вопрос «на какой известный университет вы хотите быть похожи». Нам не нужно, чтобы все выбрали себе ASU, Harvard, Oxford или UCI как аватар мечты. Это снова внешняя имитация. Вопрос другой: в каком паттерне ваш проект становится читаемым? Если вы делаете локального бота по материалам курса, он может быть слабым справочником, а может быть маленьким элементом campus platform или course service. Если вы делаете ИИ-персону, ваш паттерн может быть course persona или self-service AI-role constructor. Если вы делаете тьютора, это pedagogy-shaped dialogue. Если вы делаете проектный симулятор, это project studio. Если исследовательского ассистента — research pipeline. Если оценочный сценарий или сборщик следов — governance / assessment / добросовестность. Если вы делаете безопасную зону для тестирования — sandbox. Если вы создаёте роли, которые потом должны разворачиваться в разных курсах, — builder. Задание такое: найдите ближайший паттерн и ближайший кейс из базы. Не потому что надо копировать, а потому что кейс даёт язык. ASU помогает увидеть builder и кампусную платформу. UCI — Creator/ClassChat и зонтичную среду. Harvard или Stanford — sandbox/playground. ТюмГУ — ИИ-персоны как перераспределение функций преподавателя. Tutor CoPilot — тьютор как адаптивный контур. KAIST и Tsinghua — проектно-инженерные студии. Notre Dame — approved tools и governance. AIAS-подходы — режимы использования. Kosmos и AI Scientist — исследовательский пайплайн и AI-for-Science. Вам нужно ответить на несколько вопросов. Мой эксперимент похож на какой паттерн? Какой кейс из базы наиболее близок? Что в моём проекте локально? Что потенциально масштабируется? Что может стать элементом портфеля ТюмГУ? Что нужно описать, чтобы проект был сопоставим с другими? Последний вопрос особенно важен. Если проект нельзя сопоставить, его нельзя нормально поддерживать. Он остаётся авторской историей. Может быть хорошей, но плохо включаемой в общую работу. А нам нужна карта. Поэтому проект должен получить координату: тип ИИ, масштаб, паттерн, ближайший кейс-аналог, потенциальная большая модель. Результат задания: проект получает координату в корпусе кейсов. Не оценку, не место в рейтинге, не медальку за инновационность. Координату. С ней дальше можно работать на семинарах, в лаборатории, в портфеле. ### **Комментарии для сборки слайда** Слайд должен быть рабочей формой. Слева — список паттернов: campus platform, self-service builder, sandbox, course persona/tutor, project studio/research pipeline, governance/assessment. Справа — вопросы: мой паттерн; ближайший кейс; что локально; что масштабируется; что может стать элементом портфеля ТюмГУ; что нужно описать для сопоставимости. Внизу результат: «Проект получает координату в корпусе кейсов». Можно добавить маленькую карту: проект → паттерн → кейс-аналог → портфель. ## **Подробная сборка слайда** ### **Функция слайда** Третье задание. Оно отличается от первых двух. Задание 1: какой тип ИИ / какая природа машинности? Задание 2: какой масштаб изменения и где риск снижения? Задание 3: к какому архитектурному паттерну и месту в портфеле относится эксперимент? Это задание переводит индивидуальную идею участника в язык кейсов и портфеля. ### **Заголовок** **Задание 3\. Какой паттерн стоит за вашим экспериментом?** ### **Подзаголовок** **Разместить локальный проект в поле университетских архитектур** ### **Визуальная схема** Слева — список паттернов: * governed campus platform; * self-service builder; * sandbox / playground; * course persona / tutor; * project studio; * research pipeline; * governance / assessment; * другое / гибрид. Справа — форма ответа. **1\. Мой эксперимент ближе всего к паттерну:** --- **2\. Ближайший кейс-аналог:** --- **3\. В моём проекте локально:** --- **4\. Может масштабироваться:** --- **5\. Требует от центра / лаборатории:** --- **6\. Как элемент портфеля это:** --- ### **Главный тезис** **Эксперимент становится управляемым, когда его можно сопоставить с другими экспериментами и кейсами.** ### **Время** 10 минут индивидуально или в мини-группах. 5 минут — сбор коротких формул в чат. Формат ответа: **“Мой эксперимент \= \[паттерн\], ближайший аналог \= \[кейс/тип\], масштабируемый элемент \= \[что именно\].”** ### **Как использовать результаты дальше** Результаты задания 3 становятся основой будущей карты проектов. Если 150 проектов описаны по паттернам, сразу видно: * где много ИИ-персон; * где мало research pipeline; * где есть governance-проблемы; * где нужна единая инфраструктура; * где возможна радикальная ветка. --- --- # **Слайд 32\. Канвас: базовый экспериментальный слой \+ ИИ-архитектурный слой** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** показать мост между Ульяной и нашей установкой. **Заголовок:** **Канвас: базовый экспериментальный слой \+ ИИ-архитектурный слой** **Главная формула:** **Мы не заменяем канвас первой установки. Мы добавляем поля, которые позволяют увидеть ИИ-архитектуру и масштаб.** --- ## **Текст для выступления \+ комментарии для сборки** Теперь мы возвращаемся к канвасу. И здесь важно не сделать вид, что мы придумали новый канвас вместо первой установки. Нет. Первая установка уже дала базовый экспериментальный слой: проблема, результат, деятельность, исследовательский вопрос, гипотеза, операционализация, дизайн, ТЗ. Это ядро. Если его убрать, мы снова окажемся в мире красивых ИИ-идей без доказательности. Но теперь поверх этого слоя нужно добавить ИИ-архитектурный слой. Потому что образовательный эксперимент с ИИ недостаточно описать только через проблему и гипотезу. Нужно понять: какой тип ИИ используется, какой стек, какой масштаб изменения, какой архитектурный паттерн, какая большая модель, где риск снижения планки, какие следы остаются, какая инфраструктура нужна, с какими кейсами это сопоставляется. То есть канвас становится двухслойным. Первый слой отвечает за педагогическую и исследовательскую ответственность. Второй — за архитектурную различимость. Первый спрашивает: что мы хотим изменить и как докажем эффект? Второй спрашивает: какая ИИ-сборка это делает и как этот проект читается в большом поле? Например, базовый слой говорит: проблема — студенты не умеют формулировать исследовательский вопрос; результат — способность задавать операционализируемый вопрос; гипотеза — ИИ-критик поможет пройти цикл уточнений; дизайн — сравнить версии вопросов до и после. ИИ-архитектурный слой добавляет: это LLM-критик \+ возможно RAG по методическим материалам; масштаб — уровень 4, тренажёр функции; паттерн — research pipeline / pedagogy-shaped dialogue; риск — превращение в генератор тем; следы — версии вопросов, отклонённые формулировки, комментарии, самоотчёт; инфраструктура — логирование и интерфейс для преподавателя; кейсы-аналоги — Tutor CoPilot, research assistant, AIAS-подобные следы. Вот это уже проект, который можно обсуждать. Не идеально, но читаемо. Без второго слоя инженер не поймёт, что делать. Лаборатория не поймёт, что поддерживать. Университет не поймёт, куда это положить в портфель. А преподаватель не увидит, где его проект может деградировать. Главная формула: мы не заменяем канвас первой установки. Мы добавляем поля, которые позволяют увидеть ИИ-архитектуру и масштаб. ### **Главный тезис** **Первая установка отвечает: что и как мы исследуем. Вторая добавляет: какой ИИ-контур, в каком масштабе и внутри какой университетской модели мы проверяем.** ### **Что сказать голосом** «Сейчас мы переходим к финальной части. У вас уже есть логика эксперимента от первой установки. Мы её не заменяем. Мы добавляем второй слой. Потому что для ИИ-эксперимента недостаточно написать проблему и гипотезу. Нужно ещё понять: какой тип ИИ, какой стек, какой уровень масштаба, какой паттерн, какие следы, какой риск подмены, что требует лаборатории, как проект сопоставляется с кейсами и где он находится в портфеле». **Новые поля нужны не для отчётности, а чтобы отличить эксперимент от идеи использования инструмента.** ### **Переход** «Теперь вопрос: зачем описывать проекты в одном формате? Ответ — потому что иначе 150 проектов останутся 150 несопоставимыми историями. А нам нужна карта, поиск, сопоставление, конфигуратор, портфель». --- # **Слайд 33\. Зачем единый формат: база, поиск, конфигуратор** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** объяснить, зачем всё это описывать в едином формате. **Заголовок:** **Зачем единый формат: база, поиск, конфигуратор** **Содержание:** Если проекты описаны сопоставимо, можно: — искать похожие эксперименты; — видеть повторы; — находить взаимно усиливающие идеи; — сравнивать с мировыми кейсами; — собирать элементы решений; — использовать LLM/RAG/БД для комментариев; — готовить ТЗ; — выделять радикальные эксперименты; — собирать портфель университета. **Главная формула:** **Единый формат превращает 150 разрозненных идей в карту экспериментов.** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь вопрос: зачем всё это описывать в едином формате? Ответ простой: без единого формата мы получим сто пятьдесят разрозненных идей. С единым форматом — карту экспериментов. Разрозненные идеи плохо живут в университете. Они зависят от автора, от чата, от презентации, от памяти организаторов. Кто-то сделал похожий проект, но никто не знает. Кто-то уже проверил слабое место, но другой начинает с нуля. У кого-то есть хороший сценарий ИИ-персоны, но он не переносится. У кого-то есть сборщик следов, но он описан так, что его нельзя найти. Через несколько месяцев всё это превращается в культурный слой: вроде что-то было, вроде кто-то делал, кажется, Ульяна говорила, надо спросить в чате. Единый формат нужен не для бюрократии. Он нужен, чтобы проекты стали объектами работы. Если проекты описаны сопоставимо, можно искать похожие эксперименты, видеть повторы, находить взаимно усиливающие идеи, сравнивать с мировыми кейсами, собирать элементы решений, использовать LLM/RAG/БД для комментариев, готовить ТЗ, выделять радикальные эксперименты, собирать портфель университета. Это особенно важно для ТюмГУ, потому что уже есть материал. Если бы экспериментов было пять, можно было бы держать всё в голове. Когда их десятки и потенциально сотни, нужна база. Но база не возникает из загрузки документов. База возникает из формата. Если у одного проекта описана только проблема, у другого только промпт, у третьего только презентация, у четвёртого только эмоциональный отчёт, а у пятого только «бот помог студентам», поиск и сопоставление не работают. Единый формат превращает проект в карточку: что за контекст, какая проблема, какой тип ИИ, какая роль, какой масштаб, какой паттерн, какие кейсы-аналоги, какие следы, какие риски, какая инфраструктура, какой статус. Тогда поверх этого можно строить поиск, рекомендации, конфигуратор, семинарную критику, инженерное сопровождение. И вот здесь появляется перспектива сервиса. Не сразу. Не надо обещать, что завтра будет идеальный конфигуратор, который по трём ответам выдаст преподавателю эксперимент мечты, ТЗ, премию и внутреннее просветление. Так не бывает. Но если формат есть, можно двигаться к базе, RAG, поиску похожих проектов, подсказке паттернов, рекомендациям по рискам, подбору кейсов-аналогов, автоматизированной предварительной критике. Главная формула: единый формат превращает 150 разрозненных идей в карту экспериментов. Без него мы получим набор активностей. С ним — появляется университетская память и возможность оркестрации. ### Короткая формула: **Проект должен быть описан так, чтобы его можно было найти, сравнить, достроить, проверить и включить в портфель.** ### **Связь со следующим слайдом** Следующий слайд отвечает на вопрос: что именно должно быть в стандартном контейнере проекта. --- --- # **Слайд 34\. Стандартный контейнер кейса / проекта** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** ввести объектную карточку для будущей базы и сопоставления с кейсами. **Заголовок:** **Стандартный контейнер кейса / проекта** 1. **Главная формула:** **Проект должен быть описан так, чтобы его можно было искать, сравнивать, достраивать и критиковать.** ## **Текст для выступления \+ комментарии для сборки** ### Теперь последний шаг в этом блоке — стандартный контейнер кейса или проекта. Это не финальная анкета и не бюрократическая форма. Это объектная карточка, которая позволяет проект искать, сравнивать, достраивать, критиковать, переводить в ТЗ и включать в портфель. Карточка должна включать несколько групп полей. Первая группа — контекст. Название проекта, курс, программа, лаборатория или проектная среда. Тип деятельности: Edu, Res, Dev, Governance, Infrastructure. Без этого непонятно, где проект живёт. Один и тот же ИИ-ассистент в учебном курсе, исследовательском семинаре и проектной студии — это разные объекты. Вторая группа — экспериментальное ядро. Проблема, гипотеза эффекта, формируемая функция, образовательный или исследовательский результат. Здесь сохраняется логика первой установки. Мы не хотим потерять доказательность. Третья группа — ИИ-архитектура. Тип ИИ, стек ИИ, роль ИИ, масштаб изменения, архитектурный паттерн, большая модель, ближайшие кейсы-аналоги. Это то, чего обычно не хватает в описаниях «использования ИИ». Здесь проект становится различимым: это не просто «бот», а, например, LLM \+ RAG \+ course persona \+ уровень 4 \+ паттерн course persona/tutor \+ аналог ТюмГУ ИИ-персон и Tutor CoPilot. Четвёртая группа — роли и сценарий. Человеческие и машинные роли, сценарий взаимодействия, кто что делает, где границы помощи, где преподаватель, где студент, где лаборатория, где ИИ, где данные. Без этого легко собрать набор ботов без процесса. Пятая группа — следы, риски, инфраструктура. Какие данные остаются? Какие логи? Какие версии? Как проверяется вклад? Где риск подмены? Какие требования к интерфейсу, безопасности, базе знаний, логированию, инженерной поддержке? Что можно сделать силами преподавателя, а что требует лаборатории? Шестая группа — масштабирование и статус. Потенциал переноса, повторяемость, статус: идея, черновик, пилот, реализовано, требует ТЗ, требует инженерной поддержки, кандидат в радикальную ветку. Это кажется большим списком, но не всё должно быть заполнено идеально на первом проходе. Важно другое: если поле неизвестно, его надо обозначить как неизвестное. «Не знаем, какие логи нужны». «Неясно, требует ли проект RAG». «Нет кейса-аналога». «Риск подмены пока не описан». Это не слабость. Это честная точка для семинара. Главная формула: проект должен быть описан так, чтобы его можно было искать, сравнивать, достраивать и критиковать. Если этого нет, проект остаётся авторским рассказом. Если это есть, проект становится единицей университетского портфеля. ### **Главный тезис** **Один и тот же формат должен работать для преподавателя, семинара, лаборатории и университета.** ### **Связь со следующим слайдом** Следующий слайд раскрывает новые поля второй установки — именно те, которых не было в базовом экспериментальном контуре. --- --- # **Слайд 35\. Новые поля второй установки: ИИ-архитектура, следы, риски, инфраструктура** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** раскрыть новые поля второй установки. Это тот слайд, который склеивает прежние два, чтобы сохранить 37 слайдов. **Заголовок:** **Новые поля второй установки** **Главная формула:** **Новые поля нужны не для бюрократии, а чтобы отличить эксперимент от идеи использования инструмента.** --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь нужно сделать очень важный, почти технический, но на самом деле методологический шаг. Мы уже ввели карту типов ИИ, шкалу масштаба, архитектурные паттерны, кейсы, портфель и стандартный контейнер проекта. Всё это может звучать довольно большим слоем. Участник в этот момент вполне может подумать: хорошо, красиво, но что мне теперь конкретно дописать в мой эксперимент, чтобы он перестал быть идеей и стал проектом? Ответ: нужно добавить новые поля второй установки. Первая установка дала базовый экспериментальный контур. Там есть проблема, результат, деятельность, исследовательский вопрос, гипотеза, операционализация, дизайн, ТЗ. Это обязательно. Без этого мы получаем не эксперимент, а желание что-нибудь внедрить. Но для ИИ-эксперимента этого мало. Потому что ИИ может входить в один и тот же педагогический контур совершенно разными способами. Он может быть справочником, тьютором, критиком, персоной, аналитическим слоем, RAG по материалам, агентным workflow, исследовательским ассистентом, симулятором заказчика, сборщиком следов. И если эти различия не описаны, проект остаётся слишком мутным для реализации. Поэтому поверх базового слоя появляются три группы новых полей. Первая группа — ИИ-архитектура. Здесь мы спрашиваем: какой тип ИИ используется? Какой стек? Это просто LLM? LLM плюс RAG? Аналитика? Символический слой? Workflow? Несколько моделей? Какую роль выполняет ИИ? Он отвечает, ведёт, критикует, тренирует, моделирует, оценивает, фиксирует следы? Какова его агентность? Где он действует сам, а где только по запросу человека? Какие человеческие роли рядом: преподаватель, студент, методист, инженер, лаборатория, администрация? Какие машинные роли: персона, тьютор, критик, навигатор, симулятор, сборщик следов? Каков сценарий взаимодействия? Это поля, которые отличают «я хочу использовать ИИ» от «я понимаю, какая ИИ-сборка нужна моему эксперименту». Вторая группа — следы и добросовестность. Это особенно важно в эпоху LLM. Если мы видим только итоговый продукт, мы часто не знаем, что произошло. Студент мог сформировать способность, а мог получить гладкий результат. Команда могла пройти проектный цикл, а могла сгенерировать презентацию. Исследователь мог поставить вопрос, а мог получить обзор литературы без исследовательской позиции. Поэтому нужно спрашивать: какие следы действия остаются? Версии текста? Промпты? Реконструкция взаимодействия? Логи? Данные? Самоотчёт? Комментарии? Исправления? Отклонённые гипотезы? Критерии? Как проверяется вклад? Что сделал человек, что сделала машина, что человек проверил, что присвоил, где ошибся, где изменил позицию? Это не про полицейский контроль. Это про доказательность. Если следов нет, мы часто не можем отличить образование от производства красивой поверхности. А красивые поверхности университет и без ИИ умел делать. Цель, задачи, планируемые результаты, титульный лист — всё на месте, только живого действия иногда не обнаружено. Третья группа — риски и инфраструктура. Здесь мы спрашиваем: во что проект может деградировать? ИИ-персона может стать справочником. Тьютор — решателем задач. Критик — переписчиком. Research assistant — пересказчиком литературы. Аналитика — дашбордом ради дашборда. Governance — чекбоксом «использовал ИИ». Нужно заранее описать слабую версию проекта, иначе она почти наверняка и реализуется, просто с хорошим дизайном. И рядом инфраструктура: нужно ли логирование? Нужна ли база знаний? Нужен ли RAG? Нужен ли интерфейс? Можно ли сделать прототип силами преподавателя? Где нужна лаборатория? Где нужен инженер? Где нужна защита данных? Что должно быть в ТЗ? Что можно проверить в песочнице, а что можно сразу запускать в курсе? Вот эти поля обычно и отсутствуют. Человек говорит: «я хочу ИИ-персону». А дальше непонятно: на каких материалах она работает, что ей запрещено, как она ведёт диалог, какие следы оставляет, как преподаватель видит работу, где риск подмены, что должен сделать инженер. Или человек говорит: «я хочу автоматизировать обратную связь». Непонятно: по каким критериям, что считается помощью, что считается подменой, как студент работает со второй версией, что доказывает эффект. Поэтому новые поля нужны не для бюрократии. Они нужны, чтобы отличить эксперимент от идеи использования инструмента. Бюрократия начинается там, где поля заполняются ради формы. А здесь наоборот: поле нужно, чтобы увидеть пустоту. Если вы не знаете, нужны ли логи, так и пишите: «не знаю, какие логи нужны». Если непонятно, нужна ли база знаний, пишите: «неясно, нужен ли RAG». Если неизвестен риск подмены, пишите: «риск пока не описан». Это не слабость. Это материал для следующего семинара. На первом проходе неизвестность лучше пустой уверенности. Пустая уверенность — это когда человек бодро пишет: «ИИ повысит мотивацию и индивидуализирует обучение», а потом никто не может понять, что должно быть сделано, где это проверяется и почему это не просто общий чат. Формула: **На первом проходе достаточно указать неизвестные поля как неизвестные. Неизвестность лучше пустой уверенности.** Например: * «не знаю, нужна ли база знаний»; * «не понимаю, какие логи собирать»; * «неясно, что требует лаборатории»; * «риск подмены пока не описан». Это тоже полезный результат, потому что показывает, о чём говорить на семинаре. ### **Связь с заданием 4** Следующий слайд переводит эти поля в практическую работу: заполнить одну страницу. --- --- # **Слайд 36\. Задание 4\. Одна страница ИИ-архитектуры эксперимента** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** финальная практическая работа. **Заголовок:** **Задание 4\. Одна страница ИИ-архитектуры эксперимента** **Минимальная версия:** — проблема; — гипотеза; — тип ИИ; — уровень масштаба; — архитектурный паттерн; — сценарий; — следы; — риск подмены; — что требует лаборатории. **Продвинутая версия:** — большая модель; — кейс-аналог; — переменные мониторинга; — потенциал масштабирования; — место в портфеле. **Формат работы:** индивидуально; загрузка в чат/форму/доску; самопроверка; разбор 1–2 примеров только при наличии времени. --- ## **Текст для выступления \+ комментарии для сборки** ### Теперь финальное рабочее задание сегодняшней установки. Нам не нужно, чтобы вы сейчас сделали идеальный проект. Это невозможно и не нужно. Если бы идеальный проект можно было сделать за одно занятие, то университеты давно бы уже трансформировались при помощи формы обратной связи и трёх вдохновляющих стикеров. Нам нужно другое: чтобы у каждого появился черновик, пригодный для критики и развития. Не окончательная заявка, не отчёт, не презентация, не ТЗ. Одна страница ИИ-архитектуры эксперимента. Почему одна страница? Потому что если проект нельзя собрать на одну страницу, он пока не собран. Это не значит, что он должен быть простым. Он может быть сложным. Но его ядро должно быть предъявимо: проблема, гипотеза, тип ИИ, масштаб, паттерн, сценарий, следы, риск подмены, что требует лаборатории. Если это не помещается в одну страницу, значит, в проекте пока не различены главное и второстепенное. Здесь будет две версии: минимальная и продвинутая. Минимальная версия — для всех. В ней нужно заполнить девять полей. Первое — проблема. Не «хочу использовать ИИ», а какая трудность или разрыв в деятельности есть сейчас. Студенты не читают? Не умеют ставить вопрос? Не различают критерии? Не проходят проектный цикл? Не могут работать с источниками? Не видят ошибки в коде? Не удерживают мотивацию? Второе — гипотеза. Что изменится благодаря эксперименту? Не общая надежда, а проверяемое предположение. Например: если ИИ-критик будет возвращать студента к структуре аргумента, улучшится качество второй версии эссе. Или: если ИИ-персона будет вести диалог по материалам курса, студент сможет точнее различать ключевые понятия. Третье — тип ИИ. LLM, RAG, аналитика, символический слой, workflow, агент, симулятор, персона, тьютор, критик. Здесь важно назвать не бренд, а природу машинной функции. Четвёртое — уровень масштаба. Это оптимизация операции? Поддержка преподавателя? Средство действия студента? Тренажёр функции? Архитектура курса? Элемент университетской среды? Пятое — архитектурный паттерн. Campus platform, self-service builder, sandbox, course persona/tutor, project studio/research pipeline, governance/assessment. Или комбинация паттернов. Шестое — сценарий. Что реально делает участник? Как он входит в ситуацию? Что делает ИИ? Где преподаватель? Где материалы? Где обратная связь? Где остановка? Где новая попытка? Седьмое — следы. Что останется после взаимодействия? Версии? Логи? Промпты? Комментарии? Исправления? Самоотчёт? Данные? Карта затруднений? Без следов трудно говорить об эффекте. Восьмое — риск подмены. Во что проект может деградировать? Справочник вместо персоны? Пересказ вместо исследования? Решатель вместо тьютора? Дашборд вместо аналитики? Чекбокс вместо добросовестности? Девятое — что требует лаборатории. Что вы можете сделать сами, а где нужен инженерный контур: база знаний, RAG, интерфейс, логирование, безопасность, интеграция, прототип, тестирование? Эта минимальная версия уже достаточна, чтобы проект попал в работу семинаров. Не идеальный, но различимый. Продвинутая версия — для тех проектов, где появляется архитектурная ставка. Там добавляются большая модель, кейс-аналог, стек ИИ, переменные мониторинга, потенциал масштабирования, место в портфеле, возможная радикальная версия. Например, базовая формулировка: «ИИ-критик эссе помогает студентам улучшать аргументацию». Минимальная страница уже должна сказать: проблема — слабая аргументация; гипотеза — цикл критики и второй версии улучшает структуру аргумента; тип ИИ — LLM-критик; масштаб — уровень 4; паттерн — tutor/assessment; сценарий — студент даёт черновик, получает вопросы, пишет вторую версию; следы — две версии, комментарии, самоотчёт; риск — модель переписывает текст; лаборатория — возможно логирование и шаблон интерфейса. Продвинутая версия поднимает это в governance/assessment: как доказать вклад студента в эпоху LLM, какие следы нужны, какие задания больше не работают, какие режимы использования ИИ допустимы, как это может войти в портфель ТюмГУ. Или ИИ-персона курса. Минимально — один курс, одна персона, материалы, сценарий диалога, следы вопросов. Продвинуто — self-service builder или ecosystem of course personas: как создавать, проверять, переносить, хранить и масштабировать такие роли. Формат работы простой: индивидуально заполнить одну страницу, загрузить в чат, форму или доску, сделать самопроверку. Публично мы можем разобрать один-два примера, если останется время. Не надо превращать занятие в массовый просмотр всех проектов. При 100–150 участниках это будет не разбор, а ритуальное жертвоприношение вниманию. Главное: сегодня не нужно сделать идеальный проект. Нужно получить черновик, пригодный для критики и развития. Если он пригоден для критики, он уже живой. Если его нельзя критиковать, потому что там только общие слова, его сначала надо собрать. ### **Главный тезис** **Сегодня не нужно сделать идеальный проект. Нужно получить черновик, пригодный для критики и развития.** ### **Время** Если времени достаточно: 15–20 минут на заполнение. Если времени мало: 7–10 минут на начало заполнения, остальное — домашнее задание. ### **Самопроверка** Можно дать маленькую плашку: **Черновик живой, если понятно:** * что меняется; * что делает ИИ; * что делает человек; * какой след остаётся; * где риск подмены; * к какому паттерну относится проект; * что делать дальше. ### **Проблематизация** Опасность — участники начнут писать общие фразы: * «ИИ повысит мотивацию»; * «ИИ улучшит качество обучения»; * «ИИ поможет студентам лучше понимать»; * «ИИ сделает процесс индивидуальным». Нужно заранее сказать: «Если нельзя увидеть след, индикатор, роль ИИ и риск подмены, это пока не проектная формулировка». ### **Связь с дальнейшей работой** Эта одна страница становится входом в исследовательские семинары. Там проект будет критиковаться, уточняться, переводиться в ТЗ или пилот. --- --- # **Слайд 37\. Два следующих трека: базовый и радикальный** ## **Краткое описание (функция \+ содержание)** **Функция слайда:** финальная развилка, а не очередное повторение главной мысли. **Заголовок:** **Дальше: базовый трек и радикальный трек** **Содержание:** Две траектории. **Базовый трек:** доработать эксперимент → вынести на семинар → получить критику → дописать ТЗ → запустить → собрать отчёт. **Радикальный трек:** поднять эксперимент до архитектурного прототипа → сопоставить с мировыми кейсами → встроить в карту ТюмГУ → сформулировать R\&D / инженерную задачу → выйти на форум или отдельный доклад. **Финальная формула:** **Большинству достаточно сделать корректный эксперимент. Университету нужны ещё несколько экспериментов, которые покажут границу новой модели.** ## **Текст для выступления \+ комментарии для сборки** Теперь финальная развилка. После сегодняшней установки люди не должны выйти в хаос. Не должно быть ощущения: ну вот, нам рассказали про ИИ-архитектуры, кампусные платформы, песочницы, тьюторов, research pipeline, governance, портфели, а теперь каждый идёт домой и тихо страдает над своим ботом. Дальше есть два трека. Первый — базовый. Он для большинства участников. Его задача — довести эксперимент до запуска в логике первой установки: проблема, гипотеза, дизайн, пилот, отчёт. Это не слабый трек. Это массовый слой корректных образовательных экспериментов. В условиях реального университета, реального расписания, реальных студентов, отпусков, кафедр, нагрузок и человеческой усталости нормально проведённый эксперимент — уже большая работа. Его не надо обесценивать. Базовый трек отвечает за массовую корректность. Он даёт практику, эмпирику, первые отчёты, понимание типовых ошибок, норму работы с ИИ без истерики и без имитации. Если его не будет, программа останется красивой рамкой без материала. Второй — радикальный, или расширенный. Он не для «лучших». Это очень важно. Если назвать его треком для лучших, мы сразу испортим всю рамку. Лучший преподаватель может делать базовый эксперимент, потому что у него точная проблема, честная гипотеза и ему не нужно раздувать проект. А человек в радикальном треке может произвести красивый туман, если не удержит инфраструктурную цену. Радикальный трек нужен для тех проектов, где появляется архитектурная ставка. Не потому что автор хочет звучать крупно, а потому что сама структура проекта выходит за пределы локального курса. Например, ИИ-персона оказывается не единичным ботом, а элементом экосистемы персон. Тогда вопрос уже не только в одном курсе, а в том, как создавать такие роли, как задавать позицию, как подключать материалы, как проверять качество, как хранить удачные решения, как переносить их между курсами. Или оценивание оказывается не проверкой работ, а вопросом доказательства вклада в эпоху LLM. Тогда проект входит в governance/assessment: какие следы нужны, какие режимы использования допустимы, как отличить продукт от способности, какие задания больше не работают, где нужны устные защиты, где нужны версии, где нужен лог. Или исследовательский ассистент оказывается элементом research pipeline. Тогда вопрос уже не в том, чтобы помочь студенту собрать литературу, а в том, как поддержать цикл: вопрос, источники, гипотеза, данные, метод, анализ, интерпретация, отчёт. Или проектный симулятор оказывается началом project studio. Или сборщик следов открывает вопрос общей базы и аналитического контура. Или несколько преподавателей независимо придумывают похожие ИИ-роли, и становится понятно, что нужен не набор частных ботов, а self-service builder. Вот такие проекты нужно выносить в отдельную траекторию: архитектурный прототип, R\&D, портфель, форум, возможно инженерная задача. Их не должно быть слишком много. Если в программе 100–150 участников, неправильно ждать, что все станут авторами радикальных проектов. Это противоречит нормальному распределению времени, мотивации, ресурсов и готовности к неопределённости. Но если из всей программы появятся 5–15 сильных архитектурных прототипов, это уже может быть главным результатом. Не потому что остальные бесполезны, а потому что они выполняют другую функцию. Массовый слой даёт норму и эмпирику. Радикальный слой даёт разведку будущих моделей. Слайд должен показать две дорожки. Базовая дорожка: черновик → семинар → критика → доработка → ТЗ → пилот → отчёт. Цель — корректный образовательный эксперимент. Радикальная дорожка: черновик → усиление рамки → сопоставление с кейсами → место в портфеле → R\&D или инженерная задача → форум или отдельный доклад. Цель — прототип новой модели. И финальная мысль здесь такая: сегодня мы не заканчиваем проект. Мы правильно открываем его масштаб. После первой установки у проекта появилась педагогическая гипотеза. После второй у него должна появиться ИИ-архитектура, координата в поле кейсов и понимание траектории. Дальше начинается работа: семинары, критика, доработка, ТЗ, пилот, отчёт, портфель. Если проект останется базовым — отлично, если он честный. Если проект поднимется в радикальный трек — отлично, если он выдержит цену масштаба. Плохо только одно: назвать маленькую попытку большой трансформацией и не заметить, как она превратилась в очередной ботик, который всем понравился и ничего не изменил. Поэтому закрываем так: корректный эксперимент для всех; архитектурный прототип — для тех, где действительно появилась ставка. Университету нужны оба трека. **радикальная ветка не лучше базовой; у неё другой масштаб, другая цена и другая ответственность.** ### **Финальная фраза** **Сегодняшняя задача — не закончить проект, а правильно открыть его масштаб.** ### **Что должно остаться у участников** К концу занятия у них должно быть: * понимание типа ИИ; * понимание уровня масштаба; * понимание архитектурного паттерна; * первичный черновик одной страницы; * понимание, куда идти дальше: базовый семинарный трек или радикальная ветка. ### **Что должно остаться у организаторов** У организаторов после занятия должны появиться данные: * какие типы ИИ чаще всего предполагаются; * сколько проектов на каком уровне; * какие паттерны доминируют; * где нужна лаборатория; * где есть радикальные кандидаты; * какие проекты можно группировать. Это важно сказать себе как проектировщикам, даже если не выводить на слайд.